.NET程序集引用版本号工作机制及绑定重定向疑问

核心前提 #

CLR加载程序集时，唯一识别的版本是程序集元数据中的AssemblyVersion，而非文件版本、NuGet包版本这类辅助标识。Newtonsoft.Json的版本策略是同主版本的所有发布版，AssemblyVersion统一设为x.0.0.0（例如13.x.x版本的AssemblyVersion都是13.0.0.0），这是你遇到所有现象的根源。

你的三个假设逐一验证 #

• 假设1：引用版本x.0.0.0可兼容任意x.y.z版本的DLL？
  错误。不是x.0.0.0兼容x.y.z，而是这些x.y.z版本的Newtonsoft.Json程序集，本身的AssemblyVersion就是x.0.0.0。CLR只认AssemblyVersion，所以只要这个值匹配，不管文件实际是哪个发布版，都能正常加载。

• 假设2：在Visual Studio中添加x.y.z版本DLL引用，编译时会重置为x.0.0.0？
  错误。Visual Studio添加引用时，读取的是程序集的AssemblyVersion，而非你看到的文件版本或NuGet版本。因为你引用的13.0.3版本Newtonsoft.Json，其AssemblyVersion就是13.0.0.0，所以项目编译后引用版本显示为13.0.0.0。

• 假设3：绑定重定向无法在特定次要版本间重定向？
  错误。绑定重定向完全可以在次要版本间生效，但你的场景里，所谓的13.0.1.0、13.0.3.0根本不是Newtonsoft.Json真实存在的AssemblyVersion——官方从未发布过AssemblyVersion为这两个值的程序集。CLR找不到对应版本的程序集，自然报错；而重定向到13.0.0.0时，CLR能找到真实存在的AssemblyVersion为13.0.0.0的程序集（即你本地的13.0.3文件），所以正常运行。

实际工作机制拆解 #

1. 程序集版本的双重标识

   • AssemblyVersion：CLR加载程序集的唯一版本依据，编译时写入程序集元数据，一旦发布不可修改（除非重新编译）。
   • AssemblyFileVersion/NuGet版本：仅用于开发者识别发布版本，不参与CLR的版本绑定逻辑。

2. Newtonsoft.Json的版本兼容策略
   为了减少绑定重定向的麻烦，Newtonsoft.Json团队对同主版本的所有发布版，统一使用相同的AssemblyVersion。比如13.0.1、13.0.2、13.0.3的AssemblyVersion都是13.0.0.0，这样同主版本的程序集可以直接互相替换，无需额外配置。

3. 绑定重定向的本质
   绑定重定向是告诉CLR：当你尝试加载oldVersion范围内**AssemblyVersion的程序集时，改为加载newVersion指定的AssemblyVersion**的程序集。注意这里的版本号必须是真实存在的AssemblyVersion，而非文件或NuGet版本。

4. 你的异常场景分析
   你最初的绑定重定向配置：

   <bindingRedirect oldVersion="0.0.0.0-13.0.3.0" newVersion="13.0.3.0" />
   

   因为不存在AssemblyVersion为13.0.3.0的程序集，所以CLR无法找到目标版本，抛出异常。

   而修改后的配置：

   <bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="13.0.0.0" />
   

   CLR按照配置，将所有匹配范围内的版本请求重定向到AssemblyVersion13.0.0.0，而本地的13.0.3文件正好是这个版本标识，所以成功加载。

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