Azure DevOps构建管道启用NuGet缓存后发布旧工件问题

你的核心问题是：添加NuGet包缓存后，构建管道反复发布旧的构建工件，禁用缓存或失效缓存键则恢复正常。以下是针对性的排查思路：

1. 检查VSBuild任务的构建触发逻辑 #

• 你的NuGetCommand@2任务仅在缓存未命中时执行，但VSBuild依赖nuget restore生成的project.assets.json文件（位于项目obj目录）判断依赖状态。如果缓存命中跳过Restore，VSBuild可能读取旧的project.assets.json，误判项目无需全量构建，最终输出旧的编译结果。
• 测试方案：临时移除NuGetCommand@2的condition条件，强制每次构建都执行NuGet Restore，观察是否能生成新工件。

2. 验证VSBuild是否执行全量构建 #

• 默认情况下VSBuild采用增量构建策略，若旧的bin/obj目录残留未清理，即使代码变更，也可能仅编译修改的文件，导致输出工件未完全更新。
• 修复动作：在VSBuild任务中添加/p:Clean=true参数，强制清理旧的构建中间文件和输出：

  - task: VSBuild@1
    inputs:
      solution: '$(solution)'
      msbuildArgs: '/p:Clean=true /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
      platform: '$(buildPlatform)'
      configuration: '$(buildConfiguration)'
  

3. 检查构建工件目录的清理情况 #

• PublishBuildArtifacts@1任务会发布$(build.artifactStagingDirectory)下的所有文件，若该目录未提前清理，旧的Zip包可能被保留并重复发布。
• 修复动作：在VSBuild任务前添加清理步骤：

  - task: PowerShell@2
    displayName: 'Clean Artifact Staging Directory'
    inputs:
      targetType: 'inline'
      script: 'Remove-Item -Path "$(build.artifactStagingDirectory)/*" -Recurse -Force -ErrorAction SilentlyContinue'
  

4. 确认NuGet缓存的范围和键的有效性 #

• 检查${{ parameters.nugetPackages }}参数是否指向正确的NuGet全局包目录（通常是$(NUGET_PACKAGES)），避免意外缓存项目的bin/obj或构建输出目录。
• 验证packages.lock.json的覆盖范围：你的缓存键使用**/packages.lock.json,!**/bin/**,!**/obj/**，需确保所有项目都已生成并提交packages.lock.json文件，否则缓存键无法正确感知依赖变更，导致命中旧缓存。

5. 分析缓存命中时的构建日志 #

• 查看缓存命中管道的VSBuild日志，搜索是否存在类似Skipping target "CoreCompile" because all output files are up-to-date的记录：
  • 若存在，说明VSBuild误判代码未变更，需检查代码文件的时间戳（托管代理可能存在时间同步问题），或强制禁用增量构建。
  • 若未出现，需排查Zip打包过程是否重复使用旧文件，可查看PackageLocation目录的文件生成时间。

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