.NET编译的第三方DLL引用冲突
我正在使用 Umbraco （.NET CMS），它引用了特定版本的DLL（请参阅下面的 1 Umbraco 参考）。这很好，直到我尝试连接 .NET MailChimp API，该 API 引用同一 DLL 的不同版本（请参阅下面的 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
I am using Umbraco (a .NET CMS), and it has a reference to a specific version of a DLL (see 1 Umbraco Reference below). This is fine until I try to hook into the .NET MailChimp API which references a different vesion of the same DLL (see 2 PerceptiveMCAPI below).
I can think of a couple of options for resolving this
a. Get either the Umbraco or PerceptiveMCAPI source and reference the same version of the DLL, really do not want to do this for compatibility reasons
b. Dump the 2 DLLs in the GAC, I want to avoid this as I see deployment issues arising if someone forgets (I know we should have an automated deployment but time is restricted)
I remember that there is a third option to specify what version of the DLL to use in the configuration. Is this possible and what is the code for it?
1 Umbraco Reference
// 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这正是 GAC 存在的原因。我能想到的唯一其他解决方法是将这些 DLL 填充到子目录中，这样 CLR 就无法找到它们并实现 AppDomain.AssemblyResolve。现在，您可以为每个新版本更新维护该代码。
This is exactly the reason the GAC exists. The only other workaround I can think of is to stuff these DLLs in subdirectories so the CLR cannot find them and implement AppDomain.AssemblyResolve. You now get to maintain that code for every new version update.