Azure DevOps流水线dotnet publish步骤卡住无报错问题求助

1 基础环境与依赖排查 #

• 核对近两个月Linux服务器的网络策略、NuGet源配置是否有变更：绝大多数构建耗时异常是因为无法命中内网NuGet源，反复 fallback 到公网源超时导致。可在流水线中新增dotnet nuget list source命令打印当前生效的源配置，再用curl命令逐个测试源的访问速度与连通性。
• 同步监控流水线运行时的服务器资源占用：执行iostat、free命令确认是否存在磁盘IO过载、内存不足触发swap交换的情况，.NET Core 3.1存在内存不足时无报错卡死的已知问题。
• 确认.NET Core 3.1 SDK版本是否有变动：部分小版本SDK存在Linux环境下的构建性能bug，可固定SDK为官方最终稳定补丁版3.1.426，在项目根目录新增global.json实现版本锁定：

{
  "sdk": {
    "version": "3.1.426",
    "rollForward": "disable"
  }
}

2 构建逻辑排查 #

• 检查build/publish命令是否配置了冗余参数：确认是否误加了--no-cache、--force这类强制刷新依赖的参数，这类参数会导致每次构建全量拉取所有NuGet包，耗时暴涨。正常流水线推荐拆分步骤减少重复操作：
  • 单独执行还原：dotnet restore --source 你的内网源地址
  • 构建跳过还原：dotnet build --no-restore -c Release
  • 发布跳过构建与还原：dotnet publish --no-build --no-restore -c Release -o 输出目录
• 开启详细日志定位卡住环节：在dotnet publish命令后加-v diag参数开启诊断级日志输出，可直接定位到具体卡住的操作节点，常见卡结点包括静态资源打包、代码混淆、符号文件生成等。

3 已知问题规避 #

• .NET Core 3.1在Linux环境下存在NuGet包还原并发锁bug，如果流水线是多任务并行构建，会出现锁等待导致耗时异常，可在restore命令后加--disable-parallel参数关闭并发还原验证是否恢复正常。
• 检查是否默认开启了CI环境代码分析、单元测试覆盖率收集：部分第三方分析工具对.NET Core 3.1的Linux兼容性较差，会导致构建无响应，可临时加-p:RunCodeAnalysis=false参数关闭代码分析验证。

补充提示：.NET Core 3.1已于2022年12月停止官方支持，后续不会再发布性能、安全补丁，条件允许的话建议升级到更高LTS版本（.NET 6/8），可直接解决大量已知的Linux环境兼容性问题。

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