我正在寻找一个基于插件的应用框架，与Eclipse插件框架相似，它包括以下内容：
1. 核心插件管理框架（Equinox/OSGI），提供声明扩展端点并发现和加载服务这些端点的插件的能力。（这与依赖注入不同，但是区别微妙——配置高度分散，存在版本控制问题，可能涉及在线插件存储库，对我来说最重要的是，用户可以轻松地添加插件，而无需了解底层架构/配置文件）。
2. 提供基本工作台外壳的许多层次的插件，具有并发支持、命令、首选项表、菜单、工具栏、键绑定等功能。
这只是RCP的冰山一角，它本身旨在成为您的应用程序的基础，您通过编写/组装更多的插件来构建它。
以下是我在过去几天从互联网上搜集到的信息：
就我所知，在.NET世界中，没有任何东西能够接近Java的Eclipse RCP的强大和成熟，但有几个竞争者做得很好，其中有些做#1或#2。
（我还应该提到，我尚未就WinForms与WPF做出最终决定，因此我也试图了解任何候选框架中的UI耦合程度。我还想知道平台耦合和源代码许可证）
我必须说，开源的东西通常文档较少但易于理解，而微软的东西通常有更多的文档但不太容易理解，所以对于许多微软技术，我仍然不知道它们在实际意义上是做什么的。
这些是我发现的库：
SharpDevelop：我看到的第一件事是SharpDevelop，它在基本方式下同时完成#1和#2（没有侮辱SharpDevelop，它是令人钦佩的——我的意思是比Eclipse RCP“更基本”）。然而，SharpDevelop更像是一个应用程序而不是一个框架，有一些基本假设和限制（即与WinForms有点耦合）。尽管如此，CodeProject上有一些文章说明如何将其用作应用程序的基础。
System.Addins：它似乎旨在提供强大的插件加载框架，并具有一些复杂的选项，可以加载具有不同信任级别的程序集，甚至在进程外运行。它似乎主要是基于代码的，代码很繁重，有许多程序集用于隔离版本问题，使用指导自动化生成大量代码。到目前为止，我还没有找到许多System.AddIns文章，说明它如何用于构建类似于Eclipse RCP的东西，许多人似乎在为其复杂性而苦恼。
Mono.Addins：
似乎Mono.Addins受到了System.Addins、SharpDevelop和MonoDevelop的影响。它似乎提供了System.Addins的基础功能，但插件加载选项不够复杂，而是更加简单易懂，采用基于属性的注册、XML清单和在线插件库的基础设施。它有一个相当好的FAQ和文档，以及一套相当强大的示例，可以帮助了解如何开发类似于SharpDevelop或Eclipse的架构。这些示例使用GTK作为UI，但框架本身并未与GTK耦合。因此，它似乎非常擅长#1（加载插件），并指引#2（工作台框架）的方向。看起来Mono.Addins源自MonoDevelop，但我实际上还没有检查过MonoDevelop是否提供良好的核心工作台框架。
托管可扩展性框架是目前所有人都在谈论的东西，它的功能正在慢慢变得更加明确，但即使在阅读了SO上的几篇文章之后，我仍然感到非常模糊。官方说法是它“可以与System.Addins并行存在”。然而，它没有引用它，而且似乎重复了一些它的功能。因此，对我来说，它是System.Addins的一个更简单、更易于访问的替代品。它看起来更像Mono.Addins，它提供了基于属性的连接。它提供了可以基于属性或目录的“目录”。它似乎没有提供任何基于XML或清单的连接。到目前为止，我还没有找到什么文档和示例，而这些示例似乎有点“神奇”，更像是基于属性的DI，尽管有澄清MEF不是DI容器的说法。它的许可证刚刚开放，但它确实引用了WindowsBase——不确定它是否与Windows耦合。
我不确定Acropolis是什么。它是MEF，还是即将推出的东西？
有WPF和Winforms组合应用程序块，似乎提供更多的工作台框架。我对这些经验很少，但它们似乎相当依赖于指导自动化，并且显然与UI层耦合。有一些示例将MEF与这些应用程序块结合使用。
我已经尽力回答自己的问题，但我只是在表面上涉及了一下，我没有使用任何这些框架的经验。希望你们中的一些人可以添加关于你们使用过的框架的更多细节。如果我们能得到某种比较矩阵，那就太棒了。
1. 核心插件管理框架（Equinox/OSGI），提供声明扩展端点并发现和加载服务这些端点的插件的能力。（这与依赖注入不同，但是区别微妙——配置高度分散，存在版本控制问题，可能涉及在线插件存储库，对我来说最重要的是，用户可以轻松地添加插件，而无需了解底层架构/配置文件）。
2. 提供基本工作台外壳的许多层次的插件，具有并发支持、命令、首选项表、菜单、工具栏、键绑定等功能。
这只是RCP的冰山一角，它本身旨在成为您的应用程序的基础，您通过编写/组装更多的插件来构建它。
以下是我在过去几天从互联网上搜集到的信息：
就我所知，在.NET世界中，没有任何东西能够接近Java的Eclipse RCP的强大和成熟，但有几个竞争者做得很好，其中有些做#1或#2。
（我还应该提到，我尚未就WinForms与WPF做出最终决定，因此我也试图了解任何候选框架中的UI耦合程度。我还想知道平台耦合和源代码许可证）
我必须说，开源的东西通常文档较少但易于理解，而微软的东西通常有更多的文档但不太容易理解，所以对于许多微软技术，我仍然不知道它们在实际意义上是做什么的。
这些是我发现的库：
SharpDevelop：我看到的第一件事是SharpDevelop，它在基本方式下同时完成#1和#2（没有侮辱SharpDevelop，它是令人钦佩的——我的意思是比Eclipse RCP“更基本”）。然而，SharpDevelop更像是一个应用程序而不是一个框架，有一些基本假设和限制（即与WinForms有点耦合）。尽管如此，CodeProject上有一些文章说明如何将其用作应用程序的基础。
System.Addins：它似乎旨在提供强大的插件加载框架，并具有一些复杂的选项，可以加载具有不同信任级别的程序集，甚至在进程外运行。它似乎主要是基于代码的，代码很繁重，有许多程序集用于隔离版本问题，使用指导自动化生成大量代码。到目前为止，我还没有找到许多System.AddIns文章，说明它如何用于构建类似于Eclipse RCP的东西，许多人似乎在为其复杂性而苦恼。
Mono.Addins：
似乎Mono.Addins受到了System.Addins、SharpDevelop和MonoDevelop的影响。它似乎提供了System.Addins的基础功能，但插件加载选项不够复杂，而是更加简单易懂，采用基于属性的注册、XML清单和在线插件库的基础设施。它有一个相当好的FAQ和文档，以及一套相当强大的示例，可以帮助了解如何开发类似于SharpDevelop或Eclipse的架构。这些示例使用GTK作为UI，但框架本身并未与GTK耦合。因此，它似乎非常擅长#1（加载插件），并指引#2（工作台框架）的方向。看起来Mono.Addins源自MonoDevelop，但我实际上还没有检查过MonoDevelop是否提供良好的核心工作台框架。
托管可扩展性框架是目前所有人都在谈论的东西，它的功能正在慢慢变得更加明确，但即使在阅读了SO上的几篇文章之后，我仍然感到非常模糊。官方说法是它“可以与System.Addins并行存在”。然而，它没有引用它，而且似乎重复了一些它的功能。因此，对我来说，它是System.Addins的一个更简单、更易于访问的替代品。它看起来更像Mono.Addins，它提供了基于属性的连接。它提供了可以基于属性或目录的“目录”。它似乎没有提供任何基于XML或清单的连接。到目前为止，我还没有找到什么文档和示例，而这些示例似乎有点“神奇”，更像是基于属性的DI，尽管有澄清MEF不是DI容器的说法。它的许可证刚刚开放，但它确实引用了WindowsBase——不确定它是否与Windows耦合。
我不确定Acropolis是什么。它是MEF，还是即将推出的东西？
有WPF和Winforms组合应用程序块，似乎提供更多的工作台框架。我对这些经验很少，但它们似乎相当依赖于指导自动化，并且显然与UI层耦合。有一些示例将MEF与这些应用程序块结合使用。
我已经尽力回答自己的问题，但我只是在表面上涉及了一下，我没有使用任何这些框架的经验。希望你们中的一些人可以添加关于你们使用过的框架的更多细节。如果我们能得到某种比较矩阵，那就太棒了。