I have a C++ Windows application that can be extended by writing C++ plugins, using an API that is exposed by the application. There is also one plugin that translates the C++ API to Python (e.g. plugins can be written in Python).
I want to allow users to write plugins in C# in addition to C++ and Python. Since I'm not very familiar with the .NET world, I'm not sure how to implement the C# plugin system.
What would you recommend to use for this kind of plugin system (host is C++, plugins in C#)? What do I need to learn in order to achieve this?
There are a couple of prior posts that may help you out:
Interfacing using a simple API
Communicating between C++ and C# via DLL interface
Expose your API using COM objects and interfaces and you'll open up your application to many development environments, including C#.
Actually as well as the COM suggestions. If you really want to add 1st class .NET plugin support, its possible to host your own CLR process. There is a very interesting article here about it.
http://msdn.microsoft.com/en-us/magazine/cc163567.aspx
I've done this in various ways in the past. I found that C++/CLI was the best option for building a bridge between .Net and unmanaged C++ (though, as noted by other posters, COM in another option).
The ways I've done this in the past include:
Generating C++/CLI API wrapper code from my C++ API using reflection. Of course, native C++ has no reflection system, so we rolled our own. The generated C++/CLI code was then compiled into an assembly that the C# plugin would reference.
Generating a Dynamic Assembly from my C++ API using reflection (ie, using the Reflection.Emit stuff). The resulting assembly could be used in-process for scripting languages or you could even compile C# code against it at runtime. The assembly could even be written to disk to be used statically. The downside here is that you probably can't emit better IL than a compiler, so unless you need the dynamic generation, don't go down this path.
Hand written C++/CLI API wrappers. If the API is not very large, writing a wrapper by hand is easy enough.
In the end you will have an assembly for C# plugins to compile against. Now you need to load the plugin assemblies at runtime. To do this you must host the CLR.
Hosting the CLR is not difficult, though I've only done it once and that was a number of years ago - perhaps times have changed. If you are not comfortable with hosting the CLR, then push as muc hof your app code as possible into DLLs and then write a small C++/CLI app that brings up your unmanaged UI. Now the CLR is hosted by the small C++/CLI app.
Related
I am have been developing C# applications for a some time now, however recently I have been given a project requiring computer vision. As such my company has opted to purchase a licence for an API/SDK for a particular computer vision package. This API/SDK is however provided in:
C++, ActiveX
and Direct Show based API/SDK for integration.
My question is weather C++ libraries come in the form of .dll files or some other form?
If so what options exist to integrate the c++ API/SDK into a C# WPF program in order easily build an interface and utilise its functions? and would this be considered bad practice to mix different languages?
Would it be easier to simply develop the whole program in c++?
There are two types of libraries in C++: dll and lib.
Dll files are dynamically linked (aka only required during runtime) whereas lib files will be linked to be part of your programm.
The library probably comes as one or multiple dll files with supporting lib files for easier access of the methods (otherwise you would have to manually look for the methods in the library when using c++).
For using them from C# you have two options: building C++/CLI wrapper or import the methods using the DllImport attribute.
The wrapper method can not really be recommended. I would only use it if there is a two way communication going on between c# and c++ (and by two way I mean more than just passing basic parameters to c++ an returning basic values).
The DllImport attribute is probably what you're looking for. Information on that can be found in the MSDN ( https://msdn.microsoft.com/en-us/library/aa984739%28v=vs.71%29.aspx ).
Whether you want to write c++ yourself is up to you. If you want to create a UI and not do too much perfomance critical stuff in your own code I would just stick to C# where you feel at home ;-)
We are on the verge of writing a C# web service that will expose functionality contained in a native Delphi GUI app. Why would I choose to wrap the Delphi code in a native dll and why would I want to wrap it in a COM server? In other words: what factors do I need to consider when choosing one over the other? I am interested in factors with regard to coding, debugging, (automated) testing, deployment (installation at customers) and performance (overhead?).
COM adds some significant advantages over a plain DLL:
Support for OOP (classes, interfaces)
Automatic memory management for strings (BSTR), arrays and objects (via interfaces)
No need to use platform invoke on the .NET side
So I would go for COM.
To use a Delphi class in .NET using a DLL you have to flatten the class on the Delphi side and rewrap it on the .NET side, which is kind of ugly.
A lot of Rudy's article on Delphi and C++ code applies to C# as well:
http://rvelthuis.de/articles/articles-cppobjs.html
I am trying to write some plugins to work with the Terminal Services Session Broker Plugin Interface. I am very fluent in C# but I have not done any C++ since the late 90's. For the plugin I am writing I plan on communicating with a database and I would prefer to use System.Data.SqlClient to talk to it as I know it's ins and outs fairly well. I have the Windows SDK which has provided my with the .idl file for the interface (tssbx.idl). The SDK also provides a C header file (tssbx.h) and a C source file (tssbx_i.c).
I have never written a COM server before, and I have been having a lot of trouble finding resources on learning how to read a IDL file and turn it in to C#. Everything I find says "Use TlbImport" but that requires things like the block library to be in the IDL which tssbx.idl does not (nor its dependents) implement.
What would be my best option:
Find a tool for C# that is the equivalent to MIDL for parsing a .idl file in to a .cs file.
Learn IDL (I have been having trouble finding good guides to learn it) and write the whole thing in C# by hand.
Write a helper dll using the C files provided and have that call in to my C# dll for my .NET parts.
Re-learn C++, use the provided .h and .c files, and use the CLR to make my .NET calls.
Some other option I have not thought of.
The way to do what you're trying to do is to translate the IDL definitions into C# interfaces, then implement those interfaces as C# classes. You apply the appropriate attributes (mostly ComVisible, ClassInterface, and ProgId) to the classes you want to expose to COM, and use the regasm tool to register your assembly as a COM server.
Translating IDL into C# is actually not that complex; for the most part it maps pretty directly from IDL keywords to C# keywords and/or MarshalAs attributes. I have a series of blog posts on how to do COM interop w/out tlbimp, including one on how to read IDL. I don't know of any tools, specifically, that do a good job of this, but if its part of the Windows SDK you should always check pinvoke.net first in case someone else did it for you.
As far as your other options, 3 and 4 both amount to about the same thing. You cannot call managed code directly from unmanaged code unless it's done via COM Interop or a mixed-mode C++ library. In the first case, you'd still have to solve all of the problems of getting your C# assembly registered with COM for your C dll to call, so you may as well skip the middle-man. For the second, you are basically doing manually the same things that the runtime's interop code does for you, and using a language you're less familiar with to boot, which seems like a net loss to me.
Be aware, though, that loading .NET assemblies into an unmanaged context isn't always possible; for example, managed shell extensions are explicitly not support in Windows 2008. I don't know if the TSSBX interface will allow you to load managed assemblies as COM objects or not, so you'll have to be aware of that possibility. If you can't, then none of your options are going to work, and you'll have to avoid using the .NET Framework at all and use some other database access technology and write the entire project in unmanaged C++.
I am posting this as an answer because it is too long for a comment
From what I gather writing such plugins in .NET might raise problems later on - esp. in a scenario where more than one .NET-based plugin has to be loaded and the two (or more) plugins use different .NET versions (such problems has been expressly mentioned in the context of shell extenstions - I am just taking the reasons from that scenario as a basis for my suspicion...).
As to your option IDL itseld can't implement anything - it is an interface description language.
I would suggest using something similar to option #3 with some modification:
Implement the .NET part as a Windows Service and communicate between the C and the .NET via IPC - I would recommend using shared memory which is extremely fast and well supported with .NET4 .
I am creating a C# winforms application targeting the .NET 3.5 framework. I want this program to be able to have plugins. Hopefully the plugins can be created in unmanaged C++. If there is no direct way to make a plugin in C++, then i would like the know the easiest plugin framework that would allow me to make a simple C# wrapper for the C++ code and turn that into a plugin.
I have been researching some possible plugin frameworks, and i was wondering what your guy's feeling is about this.
System.Addin namespace
MEF
Mono.Addins
Additional Info:
I want this to be all-purpose. For example, i would like c# program to be able to handle plugins that are written in C#, an sdk written in C++ with C# swig bindings, maybe some straight up unmanaged C++ code, and possibly some python. Again, some sort of wrapper is probably necessary.
Also i would like to point out that i have never dealt with plugins before, so this is all new to me.
Well, you can just define the methods you want the plugin to implement, then load plugin dll using LoadLibrary and get pointers to needed methods using GetProcAddress. Just write a small wrapper class that will get dll name in c'tor and expose needed interface in .Net, but will forward all calls to the dll.
You do not need any framework for this wrapper.
What I suggest that you do is to create an interface for the addins (or use like System.Addins). Then create a sample addin in Managed C++ that just loads the dll using LoadLibrary and wires up the functions of the same name to their managed equivalents. You can then manage the marshalling yourself.
Then you can use a simple c# decorator around this to load any DLL addin specifically.
Is it possible to share references to C# objects between C# and C++ code without massive complexity? Or is this generally considered a bad idea?
The best solution for sharing a C# object between native and managed code is to use COM interop. This allows you to essentially share an interface of an object between managed code and it's equivalent signature in C++.
As for the complexity side of things. The majority of COM interop scenarios are straight forward and really are no more complex than good old COM programming. On the managed side it looks really no different than a normal interface.
Once you introduce multiple threads or start playing around between COM apartments though, things can get a bit tricky.
In my experience, the easiest way to get this working is the following.
Define an interface in C# that you wish to use in C++
Mark the interface with the ComVisible(true) attrbute
Run tlbexp on the assembly which generates a TLB file
Import the TLB into your native project
This will get the interface definition into both of your projects. How to pass that between the projects requires a bit more detail into your architecture.
Another solution I can recommend, from personal experience, is to use a managed C++ interface between the two if the C++ code you want to access is too large or too complex.
For example, I am using the RakNet C++ network library in a C# project. The solutions are to either create a massive wrapper class in C# to access the required C++ functions, create a C++ wrapper around those functions which can than be used as a COM interop or use Managed C++ (Visual C++/CLI).
I chose the latter which allows me to use C++ to access the RakNet library, but the classes created can be used directly in another .NET project as if. So the main logic has been created in those Managed C++ classes, which also allow me to use the .NET framework and some of its wonderful features. In my C# project I simply need to call the Managed C++ library which provides me with all in all 20 functions I need to perform everything.