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