C# NET中类似插件的体系结构

我正在尝试实现一个类似插件的应用程序。我知道已经有几种解决方案，但这只是概念的证明，仅此而已。这个想法是让应用程序主应用程序在默认情况下几乎没有特性，然后让插件相互了解，让它们实现所有需要的特性

出现了两个问题：

我希望插件在运行时通过我的应用程序相互了解。这并不意味着在编写代码时，他们不能引用其他插件的程序集以便使用其接口，只是插件功能初始化应该始终通过我的主应用程序进行。例如：如果我加载了X和Y两个插件，并且Y想要使用X的特性，它应该通过我的应用程序“注册”它的兴趣，以使用它的特性。我必须在我的应用程序中有一种“字典”，在那里我存储所有加载的插件。在我的应用程序中注册了兴趣之后，插件Y将获得对X的引用，以便它可以使用它。这是一个好方法吗

在编写使用X的插件Y时，我需要引用X的程序集，以便根据其接口编程。这就是版本控制的问题。如果我将我的插件Y编码为一个过时版本的插件X呢？我是否应该始终使用所有程序集所在的“中心”位置，始终保持程序集的最新版本

是否碰巧有专门针对.NET设计的书籍

谢谢

---

编辑：我认为人们对我提出的两个问题越来越疏远了。我可以查看MEF和#develope，但我想获得我提出的问题的具体答案。

查看

系统。AddIn

名称空间。它的级别比MEF低一点，因此应该会给您带来您想要的“自己实现它”的体验。

一旦我使用了它。我喜欢它，但那是几年前的事了，我认为现在可能有更好的解决办法。只要我还记得，基本思想是程序中有抽象类，插件继承该类并编译为DLL。。。或者使用类似的接口。不管怎样，这种方法对我很有效。后来，我添加了一个filesystemwatcher，这样它可以在运行时加载这些DLL插件

---

有一本关于构建所需内容的好书：《剖析C#应用程序：内部开发》。这里有一个链接：

---

SharpDevelop应用程序完全基于插件，本书讲述了他们是如何构建它的，他们面临的陷阱，以及他们是如何克服的。这本书在网站上免费提供，或者你也可以购买。

我建议你去看看。这是在.NET中执行插件的一种新方法。例如，这是为VS2010创建新加载项的推荐方法。我自己也没用过，但我对它的研究看起来很棒。将此添加为对其他人的激励的回答：）

关于您暴露的两个具体问题：

1） 我不确定您想要实现什么，但我猜您希望特性的延迟初始化，以及外接程序的延迟加载。如果这就是目标，那么你的建议可能会奏效。所以它可以这样工作：

• Y插件提供了它需要使用的特性列表（例如，可以通过特定的接口实现或xml清单来完成）
• X外接程序实现了一个API，该API允许使用类似Initialize（featureId）的方法初始化功能
• 宿主应用程序获取Y所需的功能列表，加载/初始化X插件，并为每个功能调用Initialize
• 宿主应用程序还提供了GetFeature（）方法，Y可以使用该方法获取对“feature”对象的引用，该对象将在X中实现

然而，如果插件Y可以直接访问X API，我认为没有必要拥有所有用于注册功能的基础设施。Y可以直接使用X API访问X特性，Y将在需要时负责惰性初始化每个特性。例如，Y可以只调用SomeXFeature.DoSomething（），该类的实现将在首次使用该功能时初始化该功能

2） 如果程序集的API发生更改，依赖于它的任何程序集都可能会中断。插件只是依赖于其他程序集的程序集，因此它们也会中断。下面是一些你可以做的事情来缓解这个问题

• 为每个插件分配一个版本号。这可能只是程序集版本
• 加载插件时，确保所有依赖项都能得到适当的满足（也就是说，它所依赖的所有插件都必须存在并且具有所需的版本）。如果无法满足依赖关系，则拒绝加载插件
• 实现一个插件管理工具，用于所有插件安装/卸载操作。当尝试安装依赖关系不满意的插件，或者尝试卸载其他插件依赖的插件时，管理器可以检查依赖关系并报告错误

---

框架使用了类似的解决方案。在Mono.Addins中，每个外接程序都有一个版本号和它所依赖的外接程序/版本列表。加载外接程序时，外接程序引擎确保也加载所有版本正确的依赖外接程序。它还提供了一个API和一个命令行工具来管理外接程序的安装。

我建议研究MEF，它是全新的，但看起来很有前途。@Matt-我想你应该把它作为一个答案-这正是我要说的我已经听说过MEF，但正如OP中所说，我的想法不是使用已经构建的框架，而是自己实现它。它不需要非常复杂的东西。@Matt-添加您的答案。MEF是一个很好的方法，如果你想知道“如何去做”，它是一个很好的起点