.NET編譯的第三方DLL參考衝突

我使用的是Umbraco（.NET CMS），它具有對特定版本的DLL的引用（請參閱下面的1 Umbraco參考）。這很好，直到我嘗試掛鉤.NET MailChimp API，它引用同一個DLL的不同組合（請參閱下面的2 PerceptiveMCAPI）。.NET編譯的第三方DLL參考衝突

我可以想出幾個方案來解決這個問題

a。獲取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

來源

2010-09-27 Burt

請注意，第三個選項只有在兩個版本之間沒有發生重大變化時才起作用，即，如果Umbraco和PerceptiveMCAPI在同一個版本中均可正常工作。 – 2010-09-27 16:46:48

我不完全確定它會起作用，但第四種選擇可能是使用ILMerge並將每個庫與它需要的版本合併，這樣就完全擺脫了引用。 – 2010-09-27 16:49:04

這是恰好的GAC存在的原因。我能想到的唯一的另一個解決方法是將這些DLL填充到子目錄中，以便CLR找不到它們並實現AppDomain.AssemblyResolve。您現在可以爲每個新版本更新維護該代碼。

來源

2010-09-27 17:09:03

就像我提到的那樣，GAC在部署時可能會出現問題。我們通常使用XCopy文件夾進行部署，如果bin中不存在DLL，它很容易被遺忘。我正在處理的解決方案最終會讓它在共享託管環境中工作，並且GAC在這種情況下不受限制。 – Burt 2010-09-27 19:16:06

你讀過第一句話了嗎？ – 2010-09-27 19:18:27

.NET編譯的第三方DLL參考衝突

回答

相關問題