.NET旧框架编译程序为何能解析新版本框架程序集？

你观察得非常到位——明明强名称程序集要求精确匹配版本，但把.NET从4.5升级到4.7后，旧应用不用重新编译就能正常跑，这背后其实是微软提前通过几个关键机制帮我们搞定了版本兼容，咱们来一步步拆解：

核心问题：为什么.NET升级后应用无需重编译仍能运行？ #

1. 发布者策略文件（Publisher Policy Files） #

微软作为.NET Framework官方发布方，每次更新框架版本时，都会把对应的发布者策略程序集安装到全局程序集缓存（GAC）里。这些文件本质是配置规则，明确告诉融合加载器：“如果有应用请求旧版本的框架程序集，直接用当前安装的新版本就行”。

举个例子，你的应用编译时引用了.NET 4.5的System.Core，但系统已经升到4.7了，发布者策略会自动让加载器去加载4.7版本的System.Core，完全不用你改配置或者重新编译。

2. 机器级默认绑定重定向 #

除了发布者策略，machine.config文件（在.NET Framework安装目录的Config文件夹里）还预存了一大堆绑定重定向规则，覆盖了几乎所有常用的框架程序集。这些规则会自动把旧版本的框架程序集请求映射到最新的兼容版本，确保所有.NET应用都能自动用上框架更新。

另外，从.NET 4.0开始还有个自动绑定重定向的机制：只要你的应用配置没禁用它，运行时会自动给兼容的程序集加上必要的重定向，进一步减少我们的手动操作。

3. 不是融合加载器的“特殊例外” #

其实框架程序集的解析并没有跳出正常的融合加载流程，只是微软提前通过发布者策略和默认配置，替我们完成了版本重定向的工作，所以看起来像是“特殊待遇”，本质上还是遵循强名称程序集的解析规则。

额外小问题：简单名称程序集的版本解析逻辑 #

微软说的“默认尝试绑定到构建时的精确版本”只针对强名称程序集，简单名称程序集的规则完全不一样：

• 简单名称程序集没有强签名，融合加载器解析时根本不会检查版本号，只会在应用目录（或者配置指定的私有路径）里找名字匹配的程序集文件；
• 所以哪怕你把简单名称程序集换成更高版本（只要接口、方法签名兼容），引用它的程序集照样能正常加载，不会出现解析失败的情况。

补充：关于Specific Version属性的澄清 #

你提到的Visual Studio里引用程序集的Specific Version = true属性，确实只在编译阶段起作用：

• 设为true时，编译必须找到和引用版本完全匹配的程序集才能通过；
• 但编译出来的程序集里，还是会包含完整的强名称信息（名称、版本、公钥令牌），运行时的解析流程根本不受这个属性影响。

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