Azure DevOps中Docker构建失败：无法加载Microsoft.CodeAnalysis程序集

这个问题我之前处理过几次，核心原因是EF Core 2.2.1分析器依赖的Roslyn（Microsoft.CodeAnalysis）版本2.8.0.0，和Hosted Ubuntu 1604代理自带的.NET Core SDK中的Roslyn版本不兼容——本地编译正常是因为你的开发环境里的SDK版本刚好匹配这个依赖版本，而云代理的SDK版本更新，导致依赖找不到。

下面是几个可行的解决方案，你可以根据项目情况选择：

方案1：升级EF Core相关包（优先推荐） #

EF Core 2.2已经是比较老的版本了，如果你项目允许，直接把Microsoft.EntityFrameworkCore.Analyzers和相关的EF Core包升级到更高版本（比如3.1.x或5.x，根据你的.NET版本兼容情况）。更高版本的分析器依赖的Roslyn版本更贴近现代SDK，能和Ubuntu代理的环境兼容，同时还能获得更多bug修复和新特性。

方案2：禁用EF Core分析器 #

如果暂时不能升级EF版本，可以直接在子模块的类库项目（.csproj）中禁用EF的分析器，避免加载这个有版本冲突的组件：

<ItemGroup>
  <!-- 移除EF Core分析器 -->
  <Analyzer Remove="Microsoft.EntityFrameworkCore.Analyzers" />
</ItemGroup>

或者如果想全局禁用所有.NET分析器（不推荐，除非必要），可以在PropertyGroup里添加：

<PropertyGroup>
  <EnableNETAnalyzers>false</EnableNETAnalyzers>
</PropertyGroup>

方案3：锁定.NET Core SDK版本和本地一致 #

既然本地编译正常，说明你本地的SDK版本和EF分析器的依赖匹配。你可以在项目根目录添加global.json文件，强制构建管道使用和本地相同的SDK版本：

{
  "sdk": {
    "version": "2.2.402" // 替换成你本地使用的具体SDK版本
  }
}

然后确保Docker构建任务中先执行dotnet restore，让管道正确下载对应版本的SDK并使用。

方案4：检查子模块的依赖恢复 #

有时候Docker构建时可能没有正确恢复子模块的NuGet依赖，你可以在Dockerfile中确保在构建前执行：

RUN dotnet restore ./path/to/your/submodule/SubmoduleProject.csproj

或者如果是多项目解决方案，直接执行dotnet restore会自动处理所有子项目和子模块的依赖。

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