.Net 和插件架构 [英] .Net and plugin architectures

问题描述

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

Following on from Jeff and Joel's discussions of plugin architectures.

C++ 中的插件(使用运行时加载的 dll)总是有点痛苦.你必须做很多基础工作来启用它们，然后插件也必须用 C++ 编写，通常甚至使用相同的编译器.COM 对象和 ActiveX 解决了其中一些问题，但引入了一些它们自己的问题.
然后补充说，python 接口，到 C++ 应用程序是大量的工作.

Plugins in C++ (using runtime loaded dlls) are always a bit of a pain. You have to do a lot of ground work to enable them and then the plugin must also be written in C++, often even with the same compiler. COM objects and ActiveX solved some of these problems but introduced a few of their own.
Then to add say, a python interface, to a C++ app is a large amount of work.

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

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 语言也使用 Winforms(或 WPF)作为 gui，那么让插件访问主应用程序的 gui 也相对简单.

Presumably since all .Net languages also use Winforms (or WPF) for the gui, then giving plugins access to the main app's gui is also relatively simple.

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

Sorry if this is a rather obvious point I'm just an old fashioned C++ programmer. But the ease of reusing existing C++ libraries via C++/CLI has convinced me that C#/.Net might be worth more investigation.

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

Edit - thanks, I was looking to discuss if plugins were a reason to go .Net . Being able to write ironpython while having my business users able to write a simple plugin in VB and technical users be able to craft something clever in F# without me doing any more work seemed a good reason to switch from C++

推荐答案

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

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.[来源]

Yes. In .NET, the cross-language compatibility is possible because of CTS (Offer a set of common data types for use across all .NET compliant languages and ensures type compatibility) and CLS (Defines a set of minimum standards that all .NET language compilers must conform to, and thus ensures language interoperability). During compilation, a source code of any .NET-compliant language is converted to Intermediate Language code by the respective language compiler. As all .NET assembly (EXE or DLL) exists as intermediate language, they can interoperate between them. All .NET compliant languages use the same data types and are represented as .NET types only. Therefore whether you are using int in C# or Integer in Visual Basic .NET, in IL it is represented as System.Int32. [Source]

这篇关于.Net 和插件架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！