I'm working on an app that I would really like to write in C#, but I need to use a library that is in C++. The vendor supplements their DLL with some C++ code to make the API more convenient, which it does, but it's still C++. I'd like to incorporate this extra C++ code into my app. It seems reasonable to create a DLL to wrap the vendor-supplied C++ code and the other calls into a module that I can use in C#.
My question is, does it make sense to wrap a DLL in another DLL? Are the potential problems I should watch out for?
Best,
John
Wrapping a wrapper for the sake of creating a better API (or, in your case, a .NET API) is OK. You might face some interop problems, as they can always pop up when moving from managed to unmanaged code.
Related
Use Case
I have a DLL written in C/C++ that is the .dll file and a .h. I need to write an ElectronJS app (.exe) with NodeJS as backend to access some function calls as part of a bigger program. I also have a C# program that has implemented a basic program that uses the DLL.
So Far
Im able to interact with some basic functions of the DLL with node-ffi-napi and ref-napi. The main problem here is that the dll uses some really big structs (>15members of short/long/DWORD/etc) and struct pointers to obtain information. While there is ref-struct-di it seems that it would be very hardwork to try to implement big structures and pointers to make an API wrapper on Node since is not native code.
Options
I think there is 3 options but since im not very familiar with Node i dont know which would be the best, what tools/packages to uses or if there is another way.
Hard work trying to implement my structs and structs* with ref-struct-di and a really extensive testing to check every parameter to see if the struct is well implemented and fail proof (seg faults) since is not a native tool.
Use the basic implemented C# tool that already does a wrapper to the dll API and have the functions implemented. Is there a way from my Node app to have some C# code running also? So i can call the C# wrapper that has native structs and see how to convert them to a dictionary so Node use them.
Implement a C++ wrapper to do similar to the C# program. This way i can access the dll api (and the .h) easier to handle the calls and structs/structs* and then from Node, call some C++ functions like for example GetInformation() and return a dictionary instead of the dll original funcion.
Since the ElectronJS app will be an .exe i need to handle everything on the same program. Its possible?
To sum everything up, what would be the best way to handle the DLL? Is there a way from Node to have some C++/C# code running also and interact with the app in runtime so i can call the dll? Anyone know any tool/package/github/link to use/read more about?
Thank you in advance.
EDIT:
Im reading about Node-API to integrate C++ code as addon. As my understanding, i will have a C++/.h files inside my Electron app and then compile everything. So my C++ code calls the DLL and then from Node i call the C++ wrapper. Is this correct?
Another way would be to create a new DLL in C++ that calls the original DLL. Then with ffi from Node access the new DLL that returns me a json/string or something less "complex" with only the info i need and not all the big structs. Right? Ideas? this way seems easier to write two separate programs without the N-API but would require two compilations.
If you had to decide between C# and Managed C++, which would you choose and why?
Are there benefits of Managed C++ over C#? Which language do you prefer? What decisions would you make under what circumstances?
I would use managed C++ if I:
Needed to integrate with existing C/C++ code
Needed to port existing C/C++ code to .net
Needed to use .NET objects from C++
Needed to expose .NET object over COM in a more complex way than what .net makes easy
Needed to access hardware directly
Needed to call lots of unmanaged APIs
And already had some skills in C++, as the above tasks will need a experienced C++ programmer. Most of the time I would only consider managed C++ if the company already had a C++ code base, otherwise who is going to maintain the managed C++ code.
In other cases I would always choose C#. Even if I choose managed C++ for part of the system, I would try to write as much of the system as possible in C#.
Think of manage C++ as a bridge building kit for going between the
unmanaged world of C/C++ and the
managed world of .NET.
If you only need to call a few simple APIs from C#, then see pinvoke.net and this overview to find how to call them from C#, as a few lines of complex pinvoke code (prebuilt bridge) in C# is normally better then introducing C++ to a project that is not already using it.
what is the benefit of managed C++
over C#?
C++.net is useful for interacting with C++ and C code (that is, calling external C or C++ libraries, providing callback functions to external modules written in C or C++ and so on.
what language of both would you
prefer?
I would prefer C# for all situations except the one described above (interacting with C and C++).
C# is easier to write, simpler, and geared specifically to use the .NET platform. C++ can do it also, but it has all the complexity of the C++ language plus the extensions needed to use the .NET platform.
Unless you need to interact with native C++ or C code, you're better off using C# in most cases (that is, if you're coding for the .NET platform).
Normally I prefer C++, but when needing to code for .NET, it doesn't beat C#.
Managed C++ is good for interop with C++: for example, if you have a .NET application and your assembly has to interact with a native interface that comes as C++ .lib files (which I had more than once), or with a nice C++ API.
Example: Rithmic (not that you ever heard of them) until recently ONLY supported a C++ API. If you try to access them from C# - good luck ;) Managed C++ allows me to access their API and expose nice .NET objects.
Basically interop. Managed C++ REALLY shines in interop with low level C / C++ API's.
I used managed C++ when I needed to build up new NET component with much ofC++ unmanaged code inside.
I did a specific class used to Marshall some objects forward and back from old C++ code.
I've encountered a problem which was transparent in managed C++, but made a big headache in C# - I had to send a callback function to a C++ unmanaged library, that defined this callback as __cdecl. In C#, the default calling convention is __stdcall, and it is pretty compilcated to move a C# delegate from __stdcall to __cdecl (Actually it requires either a 'shim' unmanaged DLL to do so or using some reflection classes).
In C++, (C++.Net as well), it is just a simple attribute.
I haven't personally written, or read for that matter, too many lines of code in managed C++, but from what I have seen it looks too convoluted and patchy. That said, you might want to use managed C++ if you are really good in C++, and when learning the idioms and patterns of a new language would be too much of a risk.
Use C# if you are quite competent in it. If you are only getting started with C++ and C#, I think, C# is the easier route to take.
I would prefer C#, or specifically .NET, over C++ because of the extensive .NET standard library.
I need to access code in a native C++ DLL in some C# code but am having issues figuring out the marshaling. I've done this before with code that was straight C, but seem to have found that it's not directly possible with C++ classes. Made even more complicated by the fact that many of the classes contain virtual or inline functions. I even tried passing the headers through the PInvoke Interop Assistant, but it would choke on just about everything and not really no what to do... I'm guessing because it's not really supported.
So how, if at all possible, can you use a native C++ class DLL from .NET code.
If I have to use some intermediary (CLR C++?) that's fine.
There is really no easy way to do this in C# - I'd recommend making a simple wrapper layer in C++/CLI that exposes the C++ classes as .NET classes.
It is possible to use P/Invoke and lots of cleverness to call C++ virtual methods, but I wouldn't go this route unless you really had no other choice.
You might have a look at SWIG, if nothing else just to see how they handle the basic wrapper code (which SWIG generates). I know next to nothing about C# native code bindings so I can't judge if their approach is sound, but they do a decent job with some of the other language bindings.
I have a native C++ DLL using DirectX, that I want to be able to use through C# to be able to create content creation tools.
Adding COM would require quite an effort it seems.
Can P/Invoke be used to maintain classes using polymorphism, or would it require me to wrap most of the code to facilitate use of P/Invoke?
It there a better solution is available? Or should I even consider writing the tools in C++ using Qt perhaps?
I always feel that C++/CLI is always the best option when doing C# to C++ interop. You can easily create thin wrappers for an unmanaged library that will look exactly like a managed library to your C# code. It also gives you more control over how marshaling and pinning is performed.
There are ways to automatically generate C++/CLI I believe, but I've never used them.
More info on C++/CLI here:
http://msdn.microsoft.com/en-us/magazine/cc163681.aspx
I presume rendering with D3D directly from C# isn't an option? (because that certainly would be easier!)
A long time ago, I used SWIG to automatically maintain C# "bindings" of my C++ rendering DLL code. It uses P/Invoke to expose the C++ objects on the C# side, and you won't have to maintain that code anymore.
You don't need to write wrap on QT.
I advice you to write Observer class both in C# & C++, and hide calls of Native functions to it.
Schema is like this
Your code in C# -> Observer(C#) -> Native call to Observer(C++) -> Calls to your dll.
I would like to call my unmanaged C++ libraries from my C# code. What are the potential pitfalls and precautions that need to be taken? Thank you for your time.
There are a couple routes you can go with this - one, you can update your unmanaged C++ libraries to have a managed C++ extensions wrapper around them and have C# utilize those classes directly. This is a bit time-consuming, but it provides a nice bridge to legacy unmanaged code. But be aware that managed C++ extensions are sometimes a bit hard to navigate themselves as the syntax is similar to unmanaged C++, but close enough that a very trained eye will be able to see the differences.
The other route to go is have your umnanaged C++ implement COM classes and have C# utilize it via an autogenerated interop assembly. This way is easier if you know your way around COM well enough.
Hope this helps.
This question is too broad. The only reasonable answer is P/Invoke, but that's kind of like saying that if you want to program for Windows you need to know the Win32 API.
Pretty much entire books have been written about P/Invoke (http://www.amazon.com/NET-COM-Complete-Interoperability-Guide/dp/067232170X), and of course entire websites have been made: http://www.pinvoke.net/.
You're describing P/Invoke. That means your C++ library will need to expose itself via a DLL interface, and the interface will need to be simple enough to describe to P/Invoke via the call attributes. When the managed code calls into the unmanaged world, the parameters have to be marshalled, so it seems there could be a slight performance hit, but you'd have to do some testing to see if the marshalling is significant or not.
The easiest way to start is to make sure that all the C++ functionality is exposed as 'C' style functions. Make sure to declare the function as _stdcall.
extern "C" __declspec(dllexport) int _stdcall Foo(int a)
Make sure you get the marshalling right, especially things like pointers & wchar_t *. If you get it wrong, it can be difficult to debug.
Debug it from either side, but not both. When debugging mixed native & managed, the debugger can get very slow. Debugging 1 side at a time saves lots of time.
Getting more specific would require a more specific question.
You can also call into unmanaged code via P/Invoke. This may be easier if your code doesn't currently use COM. I guess you would probably need to write some specific export points in your code using "C" bindings if you went this route.
Probably the biggest thing you have to watch out for in my experience is that the lack of deterministic garbage collection means that your destructors will not run when you might have thought they would previously. You need to keep this in mind and use IDisposable or some other method to make sure your managed code is cleaned up when you want it to be.
Of course there is always PInvoke out there too if you packaged your code as DLLs with external entrypoints. None of the options are pain free. They depend on either a) your skill at writing COM or Managed C wrappers b) chancing your arm at PInvoke.
I would take a look at swig, we use this to good effect on our project to expose our C++ API to other language platforms.
It's a well maintained project that effectively builds a thin wrapper around your C++ library that can allow languages such as C# to communicate directly with your native code - saving you the trouble of having to implement (and debug) glue code.
If you want a good PInvoke examples you can look at PInvoke.net. It has examples of how to call most of win api functions.
Also you can use tool from this article Clr Inside Out: PInvoke that will translate your .h file to c# wrappers.