继 Jeff 和 Joel 对插件架构的讨论之后。
C++ 中的插件(使用运行时加载的 dll)总是有点麻烦。你必须做很多基础工作才能启用它们，然后插件也必须用 C++ 编写，通常甚至使用相同的编译器。 COM 对象和 ActiveX 解决了其中一些问题，但也引入了一些自己的问题。
然后，将 python 接口(interface)添加到 C++ 应用程序是大量的工作。
我认为用一种 .Net 语言编写的所有库(或程序集或任何你称之为的东西)总是可以从另一种 .Net 语言调用，我是否正确？对象和数据类型可以在它们之间自动传输吗？
大概因为所有 .Net 语言也使用 Winforms(或 WPF)作为 gui，所以让插件访问主应用程序的 gui 也相对简单。
抱歉，如果这是一个相当明显的观点，我只是一个老式的 C++ 程序员。但是通过 C++/CLI 重用现有 C++ 库的便利性让我相信 C#/.Net 可能值得更多研究。
编辑-谢谢，我想讨论插件是否是使用 .Net 的理由。能够编写 Ironpython，同时让我的业务用户能够在 VB 中编写一个简单的插件，而技术用户能够在 F# 中制作一些聪明的东西，而无需我做更多的工作，这似乎是从 C++ 切换的一个很好的理由
最佳答案
Am I correct in thinking that all libraries (or assemblies or whatever you call them) written in one .Net language can always be called from another .Net language? And can objects an data types be automatically transferred between them?
是的。在 .NET 中，由于 CTS(提供一组通用数据类型以供所有 .NET 兼容语言使用并确保类型兼容性)和 CLS(定义一组所有 .NET 语言编译器的最低标准)，跨语言兼容性成为可能必须符合，从而确保语言互操作性)。在编译期间，任何与 .NET 兼容的语言的源代码都由相应的语言编译器转换为中间语言代码。由于所有 .NET 程序集(EXE 或 DLL)都作为中间语言存在，它们可以在它们之间进行互操作。所有 .NET 兼容语言都使用相同的数据类型，并且仅表示为 .NET 类型。因此，无论您是在 C# 中使用 int 还是在 Visual Basic .NET 中使用 Integer，在 IL 中它都表示为 System.Int32。 [ Source ]
关于.Net 和插件架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1217149/