插件/模块化架构-部署关注点

Question

我正在用.Net开发一个桌面应用程序，它遵循插件架构，如下所示：-

我有一个“核心”.Net解决方案，包含桌面exe项目和少数类库项目。这些类提供各种共享/公共功能，并由应用程序exe和各个模块引用。

每个模块都生活在自己的.Net解决方案中。该解决方案有自己的上述共享库DLL副本，模块的项目(S)引用。

最终用户安装实际上只需要将核心exe &DLL以及该站点所需的模块的DLL部署到一个文件夹中。我对核心exe用来“发现”哪些模块存在的机制没有问题，然后加载并初始化它们。

我关心的是管理和部署DLL。在理想的世界中，我应该能够对“模块X”进行更改，并且只重新部署该模块的DLL。但是，更改也可能涉及更新一个共享库是可行的。当我重新部署这些更新的DLL时，更新的共享库功能可能会破坏引用它的其他模块(甚至应用程序exe)。我想在这个场景中我应该做的是重建/重新部署所有的解决方案，而不仅仅是“模块X”。

一种更简单的方法可能是将“核心”和所有模块看作一个单一的产品，并重新部署每个版本中的所有内容，即使这只是对一个模块的更改。但是我觉得我将失去插件体系结构的一个优点--我应该能够孤立地发布一个新版本的模块。

有什么想法吗？或者这种DLL引用问题是使用插件架构不可避免的一部分？

Answer 1

我会采取这样一种方法，即共享库是核心的负责任的，模块可以根据个人的需要进行更新，除非需要对共享库进行更新。

此外，我会跟踪库的版本，方法是为每个版本的核心平台保留一个版本号，并让模块知道它们需要哪个核心版本。这将使跟踪版本不匹配问题变得更简单。

这样做的优点是，模块开发可以在很大程度上独立于核心平台和彼此进行，希望只需要偶尔对核心进行更新。

Answer 2

只要您是所有“插件”的唯一供应商，只要独立模块不需要数百MB的磁盘空间，我建议您始终将所有DLL放入每个发布的包中，并将所有内容作为一个产品来处理，只有一个版本号。这使得部署更容易，因为不需要单独的包进行部分更新，而且如果需要完整重新安装最新版本，则可以使用完全相同的包。

但是，如果您要使用您的插件体系结构来让您的模块获得它们自己的生命周期(主要是独立于核心的生命周期)，那么规划模块，就像它们是由另一个供应商提供的一样。确保模块和核心之间有一个稳定的接口，并确保模块库不会与核心库发生冲突(例如，避免将它们安装到同一个文件夹中)。即使您有一个在核心中使用的共享库，并在您的一个模块中重用，也要确保核心和模块可以同时使用该共享库的不同版本。并确保您的产品和模块有自己的版本号。然后，您可以分别部署内核和插件。

第二个选项通常会比第一个选项在配置管理方面付出更多的努力，所以仅仅“因为您有一个插件体系结构并且可以将您的模块作为不同的产品来对待”并不意味着您必须这样做，并且在将所有东西部署到一个包中时，您会丢失一些重要的东西。

Answer 3

给你三个选择，选一个你更喜欢的:)

1. 当框架实例化插件时，它应该将任何必需的框架API作为注入的接口传递给插件。这样，您就可以确定插件使用的版本与您的框架兼容。
2. 使用进程隔离，实例化它自己的进程中的每个插件。虽然这看起来像是荒谬的过度杀戮，但它也是相当糟糕的防弹衣。即使插件完全崩溃，它也不会破坏您的框架。您甚至可以在不同的用户上下文下启动每个插件，这也可能有助于保护您免受恶意插件的攻击(请参阅最小特权原则)。此选项将允许插件使用相同DLL的不同版本，甚至允许不同版本的.NET框架。
3. 要求插件认证所有插件必须提交到服务器(如果你愿意的话可以自动)，“证明”DLL是兼容的框架(也许与一些基本的自动化测试)。在验证插件之后，它可以是强命名并使用您的私钥进行签名，这样框架就可以判断它是否被篡改了。修改您的框架，使其只允许签名的插件。