.Net加載項和版本控制

Question

我們的媒體中心加載項作為單個DLL提供，它存在於GAC（mediabrowser.dll）中，我們允許用戶通過引用我們的DLL並訪問預定義的擴展點來為我們的加載項編寫擴展。

在加載時，我們搜索插件目錄，加載目錄中的所有程序集，在程序集中搜索實現IPlugin的類型，並在插件的實例上執行initialiaztion例程。 我知道這不是最強大的設計（例如：我們可能希望稍后查看appdomain隔離插件），但它現在可以正常工作。

目前看來，這似乎工作得很好，除了一個很大的警告。

當插件編寫者編譯他們的插件時，插件引用了具有特定版本的mediabrowser.dll。 稍后當我們修改我們的dll（修復bug或添加功能）時，所有針對mediabrowser.dll早期版本寫入的插件都會中斷。

我已經想到了這個問題的一些解決方案（請注意程序集在GAC中）：

1. 使用mediabrowser.dll發布發布者策略，該策略會將所有早期兼容版本的mediabrowser.dll重定向到當前版本（這也必須存在於GAC中）。
2. 發送一個單獨的程序集，其中包含所有固定的擴展點和合同，對於更改此程序集更加謹慎，讓插件編寫者鏈接到此程序集。 （但仍然考慮使用發布者策略來對接口進行不間斷的更改）
3. 讓第三方擔心這個問題，並利用MEF或其他一些處理這類內容的框架。
4. Hookup AppDomain.CurrentDomain.AssemblyResolve並將程序集的早期版本解析為當前版本。 這僅在特定版本的程序集不在GAC中時才有效。

我錯過了這個問題的其他解決方案嗎？

更新我最終選擇了4。

Answer 1

我看到你已經選擇了一個答案，但是如果你仍然對想法持開放態度還有另外一個選擇（.NET框架使用的那個）：不要在構建之間增加程序集版本（但是增加你的程序集內部版本號） 。

這將允許您的程序集保留其相同的強名稱，而不是破壞插件compat，並且仍允許您區分構建（使用程序集內部版本號）。

您可以在.NET 2.0到3.5中看到這一點。 這些版本都使用程序集版本2.0.50727，但具有不同的構建版本。

只要你不破壞你的界面合同（你永遠不應該這樣做），這種方法是非常合理的。