迁移至.NET Core 3.1后Azure Pipelines中Dotnet Publish失败（退出码1）求助

看起来你已经把Pipeline的基础流程搭好了，但卡在Publish这一步——这种Exit Code 1的通用错误确实头疼，结合你提到的SDK版本警告，我整理了几个逐步排查的方向：

• 先确认.NET Core SDK版本是否真的锁定到3.1.x
  虽然你加了Use .NET Core前置任务，但宿主agent的全局SDK可能会干扰生效。建议在Dotnet Publish任务前加一个命令行步骤，执行：

  dotnet --version
  

  输出当前使用的SDK版本，确认是不是3.1.x系列。如果不是，检查Use .NET Core任务的配置：确保Version字段填的是3.1.x，另外确认任务的作用路径是否指向你的项目根目录，避免任务没覆盖到正确的环境。

• 获取Dotnet Publish的完整错误细节
  Exit Code 1只是个通用失败码，没有实际定位价值。你需要展开Pipeline中Dotnet Publish任务的日志面板，查看更底层的错误输出——比如项目配置错误、发布路径权限问题、依赖缺失等。如果日志不够详细，可以修改Publish命令，加上详细日志参数：

  dotnet publish -v detailed
  

  这样能输出更多调试信息，帮你精准定位问题点。

• 检查项目文件的发布配置
  很多时候问题出在项目本身的设置上：

  • 确认.csproj文件里的<TargetFramework>是不是netcoreapp3.1，如果是多目标框架，有没有在Publish时指定具体框架；
  • 检查<PublishDir>或者Publish命令里的--output参数，看看路径是否包含特殊字符、存在权限限制，或者目标路径已有文件导致无法写入；
  • 排查NuGet包依赖：有没有包要求的SDK版本和3.1.x不兼容，或者存在包版本冲突的情况（虽然Restore成功，但Publish时可能触发深层依赖检查）。

• 本地复现发布流程
  在本地环境安装相同版本的3.1.x SDK，依次执行dotnet restore、dotnet build、dotnet publish命令，看能不能复现错误。如果本地也失败，那问题大概率在项目本身，和Pipeline无关；如果本地正常，再排查Pipeline和本地环境的差异：比如宿主agent的Windows版本、环境变量设置，或者Pipeline中是否有其他步骤修改了项目文件。

• 清理NuGet缓存后重试
  有时候Dotnet Restore成功了，但宿主agent的NuGet缓存可能存在损坏或不一致的情况。可以在Pipeline中添加一个前置步骤，清理缓存：

  dotnet nuget locals all --clear
  

  然后重新执行Restore和Publish，看看能不能解决问题。

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