.NET Framework 4.7 IIS应用CLR程序集绑定缓存清理时机咨询

缓存清理时机与应用池/应用启停的关系 #

CLR的先前绑定缓存是与应用域（AppDomain）强关联的：

• 在IIS中启停Web应用时，IIS会回收该应用对应的应用域并创建新实例，此时绑定缓存会被完全重置。
• 应用池是应用域的容器，同一个应用池下的Web应用共享池内的应用域资源（或按需创建独立应用域），重启应用池会回收池内所有应用域，关联的绑定缓存也会被清空。

你遇到的DLL更新但加载旧版本的可能原因 #

除绑定缓存外，还有几个常见诱因：

• 影子复制（Shadow Copy）：IIS默认对Web应用的bin目录启用影子复制，CLR会将需要加载的DLL复制到系统临时目录（如C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files）并从该目录加载。直接替换bin目录的DLL不会覆盖临时副本，必须回收应用池/重启站点才能触发重新复制。
• 程序集版本号未变更：若替换的DLL与旧版本的程序集版本号一致，CLR会判定为同一程序集，继续使用缓存的绑定结果。
• 配置文件版本锁定：web.config中的<assemblyBinding>节点可能配置了版本重定向，强制指定加载旧版本。

CLR程序集绑定的核心流程 #

1. 检查先前绑定缓存：若该程序集之前成功绑定过，直接复用缓存的路径与版本，跳过后续步骤。
2. 检查GAC：若程序集为强命名且存在于GAC，优先加载GAC中的版本（你已排除此情况）。
3. 解析配置文件：读取web.config或machine.config中的<assemblyBinding>节点，处理版本重定向、codebase路径指定等规则。
4. 应用探测规则：从应用基目录（bin目录）开始，结合配置的privatePath子目录，按照程序集的名称、版本、文化、公钥令牌等信息查找匹配的DLL文件。

相关源码参考 #

.NET Framework的CLR程序集绑定逻辑可在微软的**.NET Framework Reference Source**中查看，重点关注以下内容：

• System.Reflection.Assembly：公开的程序集加载API实现
• 内部类System.Reflection.AssemblyBinder：CLR内部的程序集绑定核心逻辑
• System.AppDomain：应用域相关的资源管理逻辑

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