.NET编译的第三方DLL参考冲突 | NET编译的第三方DLL参考冲突

本文介绍了.NET编译的第三方DLL参考冲突的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我使用一把umbraco （一个.NET CMS），它有一个参照一个DLL的特定版本（见下文1一把umbraco参考）。这是罚款，直到我试图钩到.NET MailChimp API，它引用不同的vesion相同的DLL（见下文2 PerceptiveMCAPI）。

我能想到的一对夫妇为解决这一选项

一个。获取无论是一把umbraco或PerceptiveMCAPI源和引用的DLL的版本相同，真的不希望这样做兼容性的原因

乙。转储2的DLL在GAC，我想避免这种情况，我看看是否有人忘记出现的部署问题（我知道，我们应该有一个自动部署，但时间限制）

我记得有第三个选项来指定在配置中要使用什么版本的DLL。这是可能的，什么是code呢？

1一把umbraco参考

  //大会参考CookComputing.XmlRpcV2

版本：2.4.0.0
名称：CookComputing.XmlRpcV2，版本= 2.4.0.0，文化=中性公钥= a7d6e17aa302004d

2 PerceptiveMCAPI

  //大会PerceptiveMCAPI，版本1.2.4.3


位置：C：\工作\ AEGPL \ AEGPL_Website \ BIN \ PerceptiveMCAPI.dll
名称：PerceptiveMCAPI，版本= 1.2.4.3，文化=中性公钥=空
类型：库

解决方案

这是的完全的原因GAC中存在。唯一的其他的解决办法我能想到的是在子目录东西这些DLL所以CLR无法找到他们，并实施AppDomain.AssemblyResolve。现在你到维护code，每一个新的版本更新。

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

解决方案

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.

这篇关于.NET编译的第三方DLL参考冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！