c# - 版本之间的接口(interface)变化——如何管理？

Question

这是我们在客户网站上遇到的一个相当令人不快的泡菜。客户有大约100台工作站，我们在上面部署了我们的产品“MyApp”1.0.0版本。

现在，该产品所做的其中一件事是加载一个插件(称为“MyPlugIn”，它首先在中央服务器上查找该插件以查看是否有更新的版本，如果有则它在本地复制该文件，然后使用 Assembly.Load 加载加载项并调用某个已知接口(interface)。这几个月来一直运行良好。

然后客户想在部分机器(但不是全部)上安装我们产品的 v1.0.1。它附带了新的和更新版本的 MyPlugIn。

但是问题来了。有一个共享 DLL，它被 MyApp 和 MyPlugIn 引用，称为 MyDLL，它有一个方法 MyClass.MyMethod。在 v1.0.0 和 v1.0.1 之间，MyClass.MyMethod 的签名发生了变化(添加了一个参数)。现在新版本的 MyPlugIn 导致 v1.0.0 客户端应用程序崩溃:

Method not found: MyClass.MyMethod(System.String)

客户有针对性地不想在所有客户端站点上部署 v1.0.1，因为 v1.0.1 中包含的修复仅对少数工作站是必需的，没有必要将其推广到所有客户端.遗憾的是，我们(还)没有使用 ClickOnce 或其他大规模部署实用程序，因此推出 v1.0.1 将是一项痛苦且不必要的工作。

有没有什么方法可以在 MyPlugin 中编写代码，无论它处理的是 MyDLL v1.0.0 还是 v1.0.1，它都能同样有效地工作？也许有一些方法可以在实际调用之前使用反射来探测预期的接口(interface)以查看它是否存在？

编辑:我还应该提一下 - 我们有一些非常严格的质量检查程序。由于 v1.0.1 已经由 QA 正式发布，我们不允许对 MyApp 或 MyDLL 进行任何更改。我们唯一的行动自由是更改 MyPlugin，这是专门为该客户编写的自定义代码。

Answer 1

问题是您所做的更改必须是基本上，而不是更改。因此，如果您想在您的部署中恢复兼容(据我所知，在当前的部署策略中，这是唯一的选择)，您应该永远更改界面，但是向其添加新方法并避免将插件与共享 DLL 紧密链接，但要动态加载它。在这种情况下

• 您将添加新功能而不影响旧功能

• 您将能够选择在运行时加载哪个版本的 dll。