.Net 和插件架构答案

【问题标题】：.Net and plugin architectures.Net 和插件架构
【发布时间】：2009-08-01 18:16:48
【问题描述】：

继 Jeff 和 Joel 对插件架构的讨论之后。

C++ 中的插件（使用运行时加载的 dll）总是有点麻烦。你必须做很多基础工作才能启用它们，然后插件也必须用 C++ 编写，通常甚至使用相同的编译器。 COM 对象和 ActiveX 解决了其中一些问题，但也引入了一些自己的问题。
那么，在 C++ 应用程序中添加一个 python 接口是一项很大的工作。

我是否正确地认为用一种 .Net 语言编写的所有库（或程序集或任何你称之为的）总是可以从另一种 .Net 语言中调用？对象和数据类型可以在它们之间自动传输吗？

大概因为所有 .Net 语言也使用 Winforms（或 WPF）作为 gui，所以让插件访问主应用程序的 gui 也相对简单。

对不起，如果这是一个相当明显的点，我只是一个老式的 C++ 程序员。但是通过 C++/CLI 重用现有 C++ 库的便利性让我相信 C#/.Net 可能值得更多研究。

编辑-谢谢，我想讨论插件是否是使用 .Net 的理由。能够编写 ironpython，同时让我的业务用户能够在 VB 中编写一个简单的插件，而技术用户能够在 F# 中制作一些聪明的东西，而无需我做更多的工作，这似乎是从 C++ 切换的一个很好的理由

【问题讨论】：

感谢它更多是关于插件是否是 .Net 的主要优势的讨论

标签： .net architecture plugins

【解决方案1】：

我是否正确地认为用一种 .Net 语言编写的所有库（或程序集或任何你称之为的）总是可以从另一种 .Net 语言中调用？对象和数据类型可以在它们之间自动传输吗？

是的。在 .NET 中，由于 CTS（提供一组通用数据类型以供所有 .NET 兼容语言使用并确保类型兼容性）和 CLS（定义一组所有 .NET 语言编译器的最低标准），跨语言兼容性成为可能必须符合，从而确保语言互操作性）。在编译期间，任何与 .NET 兼容的语言的源代码都由相应的语言编译器转换为中间语言代码。由于所有 .NET 程序集（EXE 或 DLL）都作为中间语言存在，它们可以在它们之间进行互操作。所有 .NET 兼容语言都使用相同的数据类型，并且仅表示为 .NET 类型。因此，无论您是在 C# 中使用 int 还是在 Visual Basic .NET 中使用 Integer，在 IL 中它都表示为 System.Int32。 [Source]

【讨论】：

+1 很棒的关于 IL 工作的 cmets。我真的没想过最终用户会用 C# 以外的东西编写插件。
有一个小问题 - 关键字差异。 C# 内置支持作为关键字的变量/成员名称（例如，@class、@if、@while 等），但并非所有其他语言都支持。如果您使用 name（它是不同 .NET 语言中的关键字），则访问该成员可能会遇到问题。我想这是一个罕见的案例，但绝对值得知道。

【解决方案2】：

如果您正在寻找 .NET 中的插件库，我知道有几个选项：

来自微软的MEF
来自 Novell (Mono) 有 Mono.Addins

两者都是开源的，因此您可以了解它们是如何创建插件环境的。

【讨论】：

【解决方案3】：

.Net 下插件的主要问题不是从插件的 dll 调用代码（并与之互操作）的能力，而是安全问题。这些也可以解决，你可以看这里（那里链接的示例也应该提供一个非常简单的主机+插件）How to create a Plugin Model in .NET with Sandbox?

对于 .Net 语言之间的互操作性 - 这没有问题。
共享 gui - 我已经用 Winforms 完成了这个，它并不难，虽然我不知道在 WPF 下它是否也那么容易，但我从未尝试过。

【讨论】：

【解决方案4】：

是的，你可以通过Reflection实现所有这些

有this one等c#插件结构的文章

【讨论】：