拆分冲突库至独立DLL仍无法解决NuGet依赖冲突，问题出在哪？

你的思路误区在于：.NET的DLL并非完全独立的执行单元，CLR在单个应用域中会统一加载程序集——不管依赖来自哪个子DLL，同名称的程序集最终只会加载一个版本（默认是最高版本，或受绑定重定向影响），所以拆分DLL并没有隔离依赖的加载上下文，冲突依然存在。

下面是可行的解决方向：

1. 优先尝试绑定重定向 #

这是.NET处理版本冲突的标准方案，不需要复杂的隔离操作。即使主项目没安装冲突的NuGet包，也可以手动在主项目的app.config（或web.config）中添加绑定重定向规则，强制CLR使用指定版本的程序集。

比如针对System.Text.Json的冲突，可添加类似配置：

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

只要两个第三方库依赖的版本API兼容，重定向到较高版本通常能解决问题。

2. 程序集隔离方案 #

如果绑定重定向无效（比如版本间API不兼容），可以通过隔离加载上下文实现版本共存：

• 使用独立AppDomain：为LibA和LibB分别创建独立的AppDomain，每个AppDomain有自己的程序集加载上下文，不同版本的依赖可以在各自域中加载。但跨AppDomain传递对象需要实现序列化，操作相对繁琐，适合复杂场景。
• 合并依赖到子DLL：用ILMerge、Costura.Fody这类工具，将LibA及其依赖的特定版本NuGet包合并成一个独立的DLL，LibB同理。合并后的DLL会包含自己所需的依赖版本，运行时不会和其他DLL的依赖冲突。注意部分强签名的NuGet包需要处理签名问题，有些库可能不支持合并。

3. 根源性修复：升级/降级依赖 #

检查冲突的NuGet包版本，看看能否升级其中一个第三方库（比如OpenCVSharp或Web相关库），使其依赖的版本与另一个库兼容。比如找到OpenCVSharp的最新版本，看是否已经更新了System.Text.Json的依赖版本，和Web库的依赖对齐，从根源消除冲突。

关于你提到的“类似C语言的静态链接”：.NET没有原生的静态链接机制，但通过ILMerge、Costura.Fody这类合并工具，可以实现类似效果——将所有依赖的程序集嵌入到目标DLL/EXE中，运行时动态提取加载，让每个子DLL真正带上自己的依赖版本，避免冲突。

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