.Net 插件和版本控制答案

【问题标题】：.Net Add-ins and versioning.Net 插件和版本控制
【发布时间】：2009-06-10 09:14:07
【问题描述】：

我们的媒体中心插件作为一个单独的 DLL 提供，它存在于 GAC (mediabrowser.dll) 中，我们允许用户通过引用我们的 DLL 并访问预定义的扩展点来为我们的插件编写扩展。

在加载时，我们搜索插件目录，加载目录中的所有程序集，在程序集中搜索实现 IPlugin 的类型并在插件实例上执行初始化例程。我知道这不是最健壮的设计（例如：我们可能想稍后查看插件的 appdomain 隔离），但它现在可以正常工作。

就目前而言，这似乎工作正常，除了一个重要的警告。

当插件编写者编译他们的插件时，插件会引用具有特定版本的 mediabrowser.dll。稍后，当我们修改我们的 dll（以修复错误或添加功能）时，针对早期版本的 mediabrowser.dll 编写的所有插件都会中断。

我已经想到了一些解决这个问题的方法（注意程序集在 GAC 中）：

使用 mediabrowser.dll 提供发布者策略，将所有早期兼容的 mediabrowser.dll 版本重定向到当前版本（这也必须存在于 GAC 中）。
发送包含所有固定扩展点和合同的单独程序集，更改此程序集时要格外谨慎，让插件编写者链接到此程序集。（但仍然考虑使用发布者策略对接口进行非破坏性更改）
让第三方担心这些事情，并利用 MEF 或其他处理这类事情的框架。
连接 AppDomain.CurrentDomain.AssemblyResolve 并将程序集的早期版本解析为当前版本。这仅在该特定版本的程序集不在 GAC 中时才有效。

对于我缺少的这个问题还有其他解决方案吗？

更新我最终选择了选项 4。

【问题讨论】：

【解决方案1】：

我看到你已经选择了一个答案，但是如果你仍然对想法持开放态度，那么还有另一种选择可以考虑（.NET 框架使用的那个）：不要在构建之间增加你的程序集版本（但要增加你的程序集版本号）。

这将允许您的程序集保留其相同的强名称，不会破坏插件兼容性，并且仍然允许您区分构建（使用程序集构建号）。

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

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

【讨论】：

问题是这会产生相当大的后续影响。我将不得不更改我的安装程序（因为 Windows 安装程序对内部版本号有点盲目）我最终会在我的 DLL 版本和 MSI 版本之间出现差异
您的程序集版本和 MSI 版本之间会存在差异，但文件版本不会存在差异（人们在查看文件详细信息时会看到）。这是我个人会采用的方法（因为它是我在多个大型商业项目中成功使用的方法），但我可以理解您希望不影响系统的愿望，尤其是当您找到满足您需求的解决方案时。