哪种外接程序/工作台框架是Eclipse RCP的最佳.NET替代方案? [英] What add-in/workbench framework is the best .NET alternative to Eclipse RCP?

问题描述

我正在寻找一个与Eclipse Plugin Framework相类似的基于插件的应用程序框架，据我简单的理解，该框架包括:

I'm looking for a plugin-based application framework that is comparable to the Eclipse Plugin Framework, which to my simple mind consists of:

1. 核心插件管理框架(Eq​​uinox/OSGI)，该框架提供了声明扩展端点，然后发现并加载为这些端点服务的插件的功能. (这与Dependency Injection不同，但可以接受的区别是细微的-配置高度分散，存在版本问题，可能涉及在线插件存储库，对我来说最重要的是，用户即可添加插件，而无需了解任何有关基础架构/配置文件的信息.
2. 许多插件层为基本工作台外壳提供并发支持，命令，首选项表，菜单，工具栏，键绑定等.

1. a core plugin management framework (Equinox / OSGI), which provides the ability to declare extension endpoints and then discover and load plugins that service those endpoints. (this is different than Dependency Injection, but admittedly the difference is subtle - configuration is highly de-centralized, there are versioning concerns, it might involve an online plugin repository, and most importantly to me, it should be easy for the user to add plugins without needing to know anything about the underlying architecture / config files)
2. many layers of plugins that provide a basic workbench shell with concurrency support, commands, preference sheets, menus, toolbars, key bindings, etc.

那只是在刮擦RCP的表面，RCP本身就是用作应用程序的基础，您可以通过编写/组装甚至更多的 more 插件来构建该应用程序.

That is just scratching the surface of the RCP, which itself is meant to serve as the foundation of your application, which you build by writing / assembling even more plugins.

这是过去几天我从互联网上收集到的信息...

Here's what I've gleaned from the internet in the past couple of days...

据我所知，.NET世界中没有什么可以远程接近Eclipse RCP for Java的健壮性和成熟度，但是有一些竞争者可以很好地完成#1或#2的竞争.

As far as I can tell, there is nothing in the .NET world that remotely approaches the robustness and maturity of the Eclipse RCP for Java but there are several contenders that do either #1 or #2 pretty well.

(我还要提一下，我还没有对WinForms vs WPF做出最终决定，所以我也试图了解任何候选框架中的UI耦合水平.我也想知道平台耦合和源代码许可)

(I should also mention that I have not made a final decision on WinForms vs WPF, so I'm also trying to understand the level of UI coupling in any candidate framework. I'm also wondering about platform coupling and source code licensing)

我必须说，开放源代码的文档通常文献较少，但更易于理解，而MS东西通常具有更多文档，但访问性较差，因此对于许多MS技术，我都想知道是什么?从实际意义上讲，他们实际上是这样做的.

I must say that the open-source stuff is generally less-documented but easier to understand, while the MS stuff typically has more documentation but is less accessible, so that with many of the MS technologies, I'm left wondering what they actually do, in a practical sense.

这些是我发现的库:

我看的第一件事是SharpDevelop，它以一种基本的方式同时实现了#1和#2(不侮辱SharpDevelop，这是令人钦佩的-我只是说比Eclipse RCP更基础 ).但是，SharpDevelop不仅仅是一个框架，而是一个应用程序，并且那里存在一些基本的假设和局限性(即某种程度上与WinForms耦合).尽管如此，CodeProject上仍有一些文章解释了如何将其用作应用程序的基础.

The first thing I looked at was SharpDevelop, which does both #1 and also #2 in a basic way (no insult to SharpDevelop, which is admirable - I just mean more basic than Eclipse RCP). However, SharpDevelop is an application more than a framework, and there are basic assumptions and limitations there (i.e. being somewhat coupled to WinForms). Still, there are some articles on CodeProject explaining how to use it as the foundation for an application.

看来System.Addins旨在提供一个健壮的加载项加载框架，其中包含一些复杂的选项，用于加载具有不同信任级别的程序集，甚至可以运行进程外.它似乎主要基于代码，并且代码繁重，使用Guidance Automation生成大量代码的大量程序集可以防止版本问题.

It appears that System.Addins is meant to provide a robust add-in loading framework, with some sophisticated options for loading assemblies with varying levels of trusts and even running the out of process. It appears to be primarily code-based, and pretty code-heavy, with lots of assemblies that serve to insulate against versioning issues., using Guidance Automation to generate a good deal of code.

到目前为止，我还没有找到许多System.AddIns文章来说明如何使用它来构建类似Eclipse RCP的东西，而且很多人似乎都在为复杂性而费心.

So far I haven't found many System.AddIns articles that illustrate how it could be used to build something like an Eclipse RCP, and many people seem to be wringing their hands about its complexity.

似乎Mono.Addins受System.Addins，SharpDevelop和MonoDevelop的影响.它似乎提供了System.Addins的基础知识，提供了较少的插件加载选项，但更为简单，具有基于属性的注册，XML清单和在线插件存储库的基础结构.

It appears that Mono.Addins was influenced by System.Addins, SharpDevelop, and MonoDevelop. It seems to provide the basics from System.Addins, with less sophisticated options for plugin loading, but more simplicity, with attribute-based registration, XML manifests, and the infrastructure for online plugin repositories.

它有一个很好的FAQ和文档，以及一组相当强大的示例，这些示例确实有助于描绘出如何开发SharpSharp或Eclipse之类的体系结构.这些示例将GTK用于UI，但是框架本身未与GTK耦合.因此，它似乎很好地完成了#1(加载加载项)的工作，并为#2(工作台框架)指明了方向.看来Mono.Addins是从MonoDevelop派生的，但是我实际上并没有研究MonoDevelop是否提供了一个好的核心工作台框架.

It has a pretty good FAQ and documentation, as well as a fairly robust set of examples that really help paint a picture of how to develop an architecture like that of SharpDevelop or Eclipse. The examples use GTK for UI, but the framework itself is not coupled to GTK. So it appears to do #1 (add-in loading) pretty well and points the way to #2 (workbench framework). It appears that Mono.Addins was derived from MonoDevelop, but I haven't actually looked at whether MonoDevelop provides a good core workbench framework.

这是当前每个人都在谈论的内容，并且它的作用正在逐步变得清晰，但是即使阅读了几则关于SO的文章，我仍然很模糊.官方的说法是它可以与System.Addins并存.但是，它没有引用它，并且似乎可以重现它的某些功能.在我看来，它是System.Addins的一种更简单，更易于访问的替代方法.

This is what everyone's talking about at the moment, and it's slowly getting clearer what it does, but I'm still pretty fuzzy, even after reading several posts on SO. The official word is that it "can live side-by-side" with System.Addins. However, it doesn't reference it and it appears to reproduce some of its functionality. It seems to me, then, that it is a simpler, more accessible alternative to System.Addins.

它看起来更像Mono.Addins，因为它提供了基于属性的接线.它提供了可以基于属性或基于目录的目录".它似乎没有提供任何基于XML或清单的连接.到目前为止，尽管澄清了MEF不是DI容器，但我还没有找到太多文档，这些示例似乎有些神奇"，并且使人联想到基于属性的DI.

It appears to be more like Mono.Addins in that it provides attribute-based wiring. It provides "catalogs" that can be attribute-based or directory-based. It does not seem to provide any XML or manifest-based wiring. So far I haven't found much documentation and the examples seem to be kind of "magical" and more reminiscent of attribute-based DI, despite the clarifications that MEF is not a DI container.

它的许可证刚刚开放，但是它确实引用了WindowsBase －不确定是否意味着它已与Windows耦合.

Its license just got opened up, but it does reference WindowsBase -- not sure if that means it's coupled to Windows.

我不确定这是什么.是MEF，还是仍在继续?

I'm not sure what this is. Is it MEF, or something that is still coming?

有WPF和Winforms Composite Application块似乎提供了更多的工作台框架.我在这些方面的经验很少，但是它们似乎完全依赖于Guidance Automation，并且显然与UI层结合在一起.有一些将MEF与这些应用程序块结合在一起的示例.

There are WPF and Winforms Composite Application blocks that seem to provide much more of a workbench framework. I have very little experience with these but they appear to rely on Guidance Automation quite a bit are obviously coupled with the UI layers. There are a few examples of combining MEF with these application blocks.

我已经尽力在这里回答自己的问题，但实际上我只是在摸索，而且我对任何这些框架都没有经验.希望你们中的一些人可以添加有关您经验丰富的框架的更多详细信息.如果能够得到某种比较矩阵，那就太好了.

I've done the best I could to answer my own question here, but I'm really only scratching the surface, and I don't have experience with any of these frameworks. Hopefully some of you can add more detail about the frameworks you have experience with. It would be great if we could end up with some sort of comparison matrix.

推荐答案

+1 for SharpDevelop.这些库编写良好，并且易于扩展.我实际上是在使用SharpDevelop Core及其外接程序基础结构来编写自己的代码重构应用程序.

+1 for SharpDevelop. The libraries are well-written and simple to extend. I'm actually writing my own code refactoring application using the SharpDevelop Core and their Addin infrastructure.

很好.

-道格

这篇关于哪种外接程序/工作台框架是Eclipse RCP的最佳.NET替代方案?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！