log4net版本冲突求助：Web调用旧版DLL时提示找不到2.0.12.0

问题 #

• Web应用通过DLL与客户端应用的API交互
• 此前运行正常，直到需要创建适配旧版客户端的DLL版本：旧版客户端用log4net 2.0.8.0，新版用2.0.12.0
• Web应用调用新版DLL时报错：提示尝试使用log4net 2.0.12.0但无法找到

已完成的排查：

• 所有log4net引用均指向2.0.8.0版本
• 所有依赖log4net的NuGet包均使用2.0.8.0（曾有一个用2.0.7.0，已修正）
• 清空了所有编译缓存
• 检查GAC，无相关内容
• 错误针对本地DLL，非服务器端Web应用，双方均为64位，无位数兼容问题

异常细节：DLL中无任何log4net 2.0.12.0的引用，但Web调用时仍提示需要该版本；更诡异的是，错误信息中2.0.12.0对应的PublicKeyToken实际是2.0.8.0的。尝试用AssemblyResolve强制绑定2.0.8.0，无效，仍提示需要2.0.12.0。

下一步排查方向 #

1. 检查DLL的清单文件
   用ILSpy、dotPeek这类反编译工具打开目标DLL，查看其Manifest清单，确认是否存在对log4net 2.0.12.0的硬编码引用——编译过程中可能会把依赖版本信息写入清单，即使代码里没有直接引用。
2. 扫描客户端API的依赖树
   你的DLL调用旧版客户端API，要确认旧版客户端API内部是否间接引用了log4net 2.0.12.0，或者其依赖的组件是否偷偷加载高版本log4net。用依赖扫描工具（如NuGet Package Explorer、dotnet list package）梳理客户端API的完整依赖链。
3. 验证Web应用的绑定重定向配置
   检查Web应用的web.config，确认log4net的版本绑定重定向是否配置正确：

   <dependentAssembly>
       <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" culture="neutral" />
       <bindingRedirect oldVersion="0.0.0.0-2.0.12.0" newVersion="2.0.8.0" />
   </dependentAssembly>
   

   注意PublicKeyToken要和你使用的2.0.8.0版本匹配，同时确保配置文件没有被其他子配置或部署脚本覆盖。
4. 检查编译输出目录的实际文件
   去到Web应用的bin等编译输出目录，右键查看log4net.dll的属性“详细信息”，确认实际存在的文件版本和PublicKeyToken是否为2.0.8.0——有时NuGet还原不彻底，会残留旧版本文件。
5. 排查AssemblyResolve事件的有效性
   确认AssemblyResolve事件是否在错误发生前就完成注册（比如应用启动初期），如果注册太晚就无法拦截加载请求。同时检查事件处理逻辑，确保正确返回了2.0.8.0版本的程序集实例。
6. 排查第三方工具的动态注入
   某些监控、诊断工具或AOP框架可能会动态修改程序集依赖，比如替换log4net版本。检查Web应用是否使用了这类工具，是否有相关配置影响了依赖加载逻辑。

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