Azure DevOps代理构建正常但本地.NET5构建失败原因排查

两边构建结果不一致的核心原因是本地和Azure DevOps流水线编译时使用的.NET SDK版本、默认编译配置不匹配，导致可空引用类型警告CS8603的触发逻辑不一致。

细节逻辑 #

• 本地构建行为：
  本地环境安装了.NET 6.0.301 SDK，代码库根目录没有global.json固定SDK版本时，dotnet build会遵循默认版本选择规则，自动调用本机安装的最高主版本SDK（即6.0.301）来编译目标框架为.NET 5的项目。.NET 6 SDK自带的Roslyn编译器版本更高，对未显式配置<Nullable>属性的项目，会默认执行部分可空引用类型扫描，识别出代码中可能返回空引用的CS8603问题。结合你在Directory.Build.props中配置的<TreatWarningsAsErrors>True</TreatWarningsAsErrors>规则，该警告被直接提升为编译错误，导致本地构建失败——这也是为什么在VS2022外部直接执行命令行构建也会复现问题，和IDE本身的配置无关。
• Azure DevOps流水线构建行为：
  使用的官方「.NET Core」->「Build」任务针对.NET 5及更早版本的项目有默认编译参数逻辑，会隐式关闭未显式开启的可空引用类型分析；同时任务默认会优先选择和项目目标框架大版本匹配的SDK（即构建代理上安装的5.0.402/5.0.408）执行编译。.NET 5 SDK自带的Roslyn编译器不会对未显式开启<Nullable>配置的项目触发CS8603警告，因此不存在警告转错误的问题，构建可以正常通过。

修复方式 #

任选一种方案即可对齐两边构建结果：

1. 在代码库根目录添加global.json文件，强制所有环境构建时使用指定版本的.NET SDK，从根源避免版本差异，示例配置：

{
  "sdk": {
    "version": "5.0.408",
    "rollForward": "latestPatch"
  }
}

2. 在Directory.Build.props中显式声明可空引用类型的启用状态，屏蔽不同SDK的默认行为差异：如果暂时不需要处理可空相关问题，添加<Nullable>Disable</Nullable>配置；如果需要全链路做可空检查，则添加<Nullable>Enable</Nullable>，确保所有环境的编译规则统一。
3. 在Azure DevOps流水线中提前添加「Use .NET Core」任务，显式指定使用6.0.301版本的.NET SDK执行构建，让流水线环境和本地默认编译环境对齐。

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