csc/Roslyn程序集版本解析机制及ClosedXML依赖冲突疑问

核心问题：编译时元数据版本匹配 vs NuGet依赖解析 #

这不是NuGet依赖优先机制失效，而是编译阶段的程序集元数据匹配逻辑和NuGet的依赖安装逻辑完全独立：

• NuGet的直接依赖优先是解决「下载哪个版本的包到本地」的问题，它确实会把你指定的ClosedXML v0.97安装到项目中。
• 但编译时Roslyn（csc.exe背后的编译器）需要严格匹配类型元数据中记录的程序集版本——ClosedXML.Report 0.2.4是基于ClosedXML v0.95编译的，它的XLTemplate类及其内部依赖的所有ClosedXML类型，元数据里都标记为需要ClosedXML, Version=0.95.0.0。

.NET Core程序集解析的编译/运行时差异 #

.NET Core的自动版本重定向是运行时行为，编译阶段没有这个自动兼容逻辑：

• 运行时：CLR会自动将旧版本的程序集请求重定向到项目中已有的最新兼容版本（只要版本号递增、无破坏性变更）。
• 编译时：Roslyn必须找到与元数据版本完全匹配的程序集，否则就会抛出CS0012错误——它不会主动假设高版本能兼容低版本的元数据。

Roslyn的版本选择逻辑 #

编译过程中，Roslyn的执行步骤：

1. 解析代码中直接引用的XLTemplate类，读取它的元数据。
2. 递归解析XLTemplate依赖的所有类型，发现其中依赖ClosedXML v0.95的类型。
3. 检查当前项目的引用程序集列表，寻找版本完全匹配的ClosedXML程序集。
4. 找不到时直接抛出CS0012，不会尝试用高版本替代——除非显式配置了程序集绑定重定向。

解决办法 #

• 配置自动绑定重定向：在项目文件（.csproj）中添加以下配置，让MSBuild自动生成编译时的版本重定向规则：

  <PropertyGroup>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
  </PropertyGroup>
  

• 升级ClosedXML.Report：如果存在支持ClosedXML v0.97的ClosedXML.Report版本，直接升级到该版本，从根源上解决元数据版本不匹配的问题。
• 临时降级ClosedXML：手动将ClosedXML的直接依赖版本改为v0.95，但这会放弃高版本特性，仅作为临时应急方案。

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