Azure DevOps中dotnet restore成功但build找不到NuGet包异常

结合你提供的流水线配置和运行现象，所有异常都源于3个可复现的配置错误：

• 命令参数误用：dotnet build的--source参数仅用于指定NuGet下载源的地址，不能传入本地文件夹路径来告知构建进程已还原包的存储位置，传入本地相对路径完全不具备包检索能力。
• 还原路径配置不统一：你通过dotnet restore任务的restoreDirectory参数将包存储到根目录packages文件夹，但构建阶段启用--no-restore时，NuGet会默认从全局包缓存目录检索包，完全不会扫描你自定义的packages目录，因此出现程序集引用缺失。
• 偶发失败的触发逻辑：构建步骤配置了workingDirectory: Booking.Server，不同版本的Azure Pipelines代理对相对路径的解析基准存在差异，当代理把../packages解析到非预期路径时，就会触发引用错误；当代理路径解析刚好命中包位置时，流水线就会偶然成功。

你遇到的The type or namespace name 'Migrations' does not exist in the namespace 'Microsoft.EntityFrameworkCore' 报错，属于路径不匹配触发的连锁反应，并非项目本身的csproj包引用缺失，和你检查到的csproj无本地路径引用的状态完全匹配。

• 移除构建命令中无效的--source ..\packages参数，停止将本地包路径传入NuGet源配置。
• 统一包路径的配置逻辑：在Booking.Server/NuGet.config中添加全局包路径配置，把还原、构建阶段的包检索路径强制统一。参考配置：

  <configuration>
    <config>
      <add key="globalPackagesFolder" value="../packages" />
    </config>
    <!-- 你已配置的公共NuGet源、私有GitLab NuGet源配置保持不变 -->
  </configuration>
  

• 调整dotnet restore任务配置：删除任务输入项中的restoreDirectory: packages，该参数优先级高于NuGet.config配置，保留会造成路径冲突。
• 优化流水线清理逻辑：在restore步骤前添加清理任务，删除所有项目下的bin、obj目录，避免旧的project.assets.json残留错误的包路径记录，触发偶发异常。
• 临时验证调整：首次验证构建时，去掉--no-restore参数，让构建进程自动执行一次还原流程，确认包路径读取正常后，再逐步恢复构建参数优化流水线运行效率。
• 修正流水线显示名称的拼写错误：将Check pakcages改为Check packages，降低后续维护的识别成本。

内容的提问来源于stack exchange，提问作者Ben