.NET编译第三方DLL引用冲突答案

【问题标题】：.NET compiled third-party DLL reference conflict.NET编译第三方DLL引用冲突
【发布时间】：2010-09-27 16:32:02
【问题描述】：

我正在使用Umbraco（.NET CMS），它引用了特定版本的 DLL（请参阅下面的 1 Umbraco 参考）。这很好，直到我尝试连接到引用同一 DLL 的不同版本的 .NET MailChimp API（请参阅下面的 2 PerceptiveMCAPI）。

我可以想到几个解决这个问题的方法

一个。获取 Umbraco 或 PerceptiveMCAPI 源并引用相同版本的 DLL，出于兼容性原因真的不想这样做

b.转储 GAC 中的 2 个 DLL，我想避免这种情况，因为如果有人忘记了会出现部署问题（我知道我们应该进行自动部署，但时间有限）

我记得有第三个选项可以指定在配置中使用什么版本的 DLL。这可能吗？它的代码是什么？

1 Umbraco 参考

// Assembly Reference CookComputing.XmlRpcV2

Version: 2.4.0.0 
Name: CookComputing.XmlRpcV2, Version=2.4.0.0, Culture=neutral, PublicKeyToken=a7d6e17aa302004d

2 PerceptiveMCAPI

// Assembly PerceptiveMCAPI, Version 1.2.4.3


Location: C:\Work\AEGPL\AEGPL_Website\bin\PerceptiveMCAPI.dll 
Name: PerceptiveMCAPI, Version=1.2.4.3, Culture=neutral, PublicKeyToken=null 
Type: Library

【问题讨论】：

请注意，第三个选项只有在两个版本之间没有重大更改时才有效，即，如果 Umbraco 和 PerceptiveMCAPI 都可以在相同版本上正常工作。
我不完全确定它会起作用，但第四个选项可能是使用 ILMerge 并将每个库与其所需的版本合并，这样就完全摆脱了引用。

标签： c# .net vb.net dll gac

【解决方案1】：

这正是 GAC 存在的原因。我能想到的唯一其他解决方法是将这些 DLL 填充到子目录中，这样 CLR 就无法找到它们并实现 AppDomain.AssemblyResolve。您现在可以为每个新版本更新维护该代码。

【讨论】：

就像我提到的那样，GAC 在部署方面可能会出现问题。我们通常 XCopy 文件夹进行部署，如果 bin 中不存在 DLL，它很容易被遗忘。我正在研究的解决方案我最终希望它能够在共享托管环境中工作，而 GAC 在这种情况下是不受限制的。