.Net and plugin architectures

Question

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

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.

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?

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.

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.

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++

Answer 1

The main problem with plugins under .Net is not the ability to call the code from plugin's dll (and interop with it), but safety issues. Those can be solved as well, you can look here (ones of sample that is linked there also should present a very simple host + plugin) http://stackoverflow.com/questions/1197426/how-to-create-a-plugin-model-in-net-with-sandbox/1197470#1197470

And for interoperability between .Net languages - there's no problem with that.
Shared gui - I've done this with Winforms, and it wasn't very hard, although I don't know if it would be also that easy under WPF, I've never tried it though.

Answer 2

Yeah , you can achieve all of them through Reflection

there are articles about c# plug-in structure such as this one

Answer 3

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?

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]

Answer 4

If you are looking for plug-ins libraries in .NET, there are a couple of options I am aware of:

• From Microsoft there is MEF
• From Novell (Mono) there is Mono.Addins

Both are open source, so you can see how they went about creating a plug-in environment.