Here's a simple question (kind of), but I'm having a hard time taking a decision. First, a history on how I came to have this problem. In my new job, we need to use a third party API to communicate with their proprietary database (this is manufacturing technologies). This API only comes with very simple c example (not simple syntax 😉 ) on how to use this API. Functions have no documentations and the syntax is thick, since it was probably build sometime in the last century, so parameters have short non significant names same with the functions names.
Very few help is found on the web and the company itself can't really help us. Over the web, the small crumb found are about people not able to translate it into simpler language call (like VB6). People before me here tried to use it, without success.
The good news is I have been able to make the example work and modified them to fit our basic needs to send or read data. I have wrapped these new version in a c++/CLR assembly dll, to use it in c#, which is our almost current language(Yeah , it moves slow in this world)
Depending on the version of the software we use (every client we have can have different setup, from legacy to brand new setup). This can have an influence an what language we use. So I was asked to try and make my dll available in native & managed setting.
So, here lies my question. Should I leave my dll to have a managed signature and if it needs to be use in vb6, make sure it is understood how to make it work in native mode (which I need to learn), or should I make a native dll and make it P/Invoke in managed setting? Or should I build two distinct dll? IMO, I would keep it as a managed dll, but I was wondering if it's the best way to do it?
On a last note, the current version is a v.1 build to showcase how we can use it,and start using it fast. Writing this makes me realize I need to build an interface!:). I plan to rebuild the whole program, but the API's calls will always be to their native dll, unless they have .net SDK coming, but no word about it yet.
Best Answer
There are two drawbacks to keeping just the managed DLL:
a) you will need the .NET Framework on the target machine
b) there will be two layers of marshaling between an unmanaged caller and the code you've wrapped: a COM Callable-Wrapper between the native caller and the COM interface of your .NET Assembly, and the managed-unmanaged transition between your wrapper and the inner code - this may be a serious performance hit if you're marshaling a lot, and it may be complex if your interface to the callers is wide.
If neither of these is a real problem (i.e. adding the CCW in terms of performance and complexity), then you have no other direct incentive that I can see to modify your current solution.
As far as extensibility goes, if you plan to add managed code to the wrapper - if you need to complement the solution you're wrapping and need to add stuff to it at the low-cost of managed code, then you're pretty much stuck with the managed DLL, because presumably both the VB6 callers and the managed callers would need the new functionality. If, on the other hand you need to add native code, then you could still add it to the unmanaged CLI part of the managed DLL.