.Net外接程序和版本控制

Question

我们的媒体中心外接程序是作为一个驻留在GAC (mediabrowser.dll)中的单个DLL提供的，我们允许用户通过引用DLL和访问预定义的扩展点来为我们的外接程序编写扩展。

在加载时，我们搜索插件目录，加载目录中的所有程序集，在程序集中搜索实现IPlugin的类型，并在插件实例上执行初始化例程。我知道这并不是最健壮的设计(例如:我们以后可能想看看插件的应用程序域隔离)，但它现在工作得很好。

就目前情况而言，这似乎很好，除了一个大的警告。

当插件作者编译他们的插件时，插件引用了特定版本的mediabrowser.dll。稍后，当我们修改dll (以修复bug或添加特性)时，所有针对mediabrowser.dll中断早期版本编写的加载项。

我想出了一些解决这个问题的方法(注意，总成在GAC中)：

1. 提供了带有mediabrowser.dll的发行者策略，该策略将将所有早期兼容的mediabrowser.dll版本重定向到当前版本(这也必须位于GAC中)。
2. 提供了一个单独的程序集，其中包含所有固定的扩展点和契约，在更改此程序集时要格外谨慎，有插件编写器与此程序集的链接。
3. 让第三方担心这些内容，并利用MEF或其他处理此类内容的框架。
4. Hookup AppDomain.CurrentDomain.AssemblyResolve并将程序集的早期版本解析为当前版本。只有当该特定版本的组装不在GAC中时，这才能起作用。

对于这个问题，我还有其他的解决办法吗？

Update I最后选择了选项4。

Answer 1

我知道您已经选择了一个答案，但是如果您仍然对想法持开放态度，那么还有另一个选项需要考虑( .NET框架使用的那个选项)：不要在构建之间增加程序集版本(而是增加您的程序集构建号)。

这将允许您的程序集保留其相同的强名称，而不是破坏插件公司，并且仍然允许您区分构建彼此(使用程序集生成号)。

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

只要您不破坏您的接口契约(无论如何您都不应该这样做)，这种方法是相当合理的。