How to use a C++ project from within a .NET application?

Question

I'm a regular .NET developer aiming to integrate a C++ library into a .NET project. I have a few ideas, but since I'm new to C++ in general I don't know the limits of the technology I'm trying to work with. The C++ project is essentially a fast sound renderer that can playback multi-track audio files with a bunch of different postprocessing tricks. All of this is cool, but considering I have a simple .NET WinForms app I want to integrate with, things start to look messy.

1. Firstly, the C++ project has no .NET bindings or ActiveX/COM integration. Its a plain 'ol MS VC++ 9 project. If I am to work with the project in my .NET app I'll have to somehow interface with it, ie. create class instances, set properties, call methods, marshal data in and out, etc.

2. Secondly, its built to run as an independent Windows app and manages its own windows using the MS Windows API. This is fine, but somehow I need the .NET VM running in the background, managing the show and running all my C# code. I don't write C++ so I need to stick with C# to build an app around this lib.

3. Thirdly, whether I'm running in the same process as the C++ lib or not, I need a way to build/interface/debug these 2 separate apps as if they were one. I have no background in C++ programming except for the fact that I have written a couple C++ DLLs for high-performance data manipulation.

So, many questions and no idea how to start!

• I can fully compile this lib and get it into a VC EXE, but how do I co-compile my .NET code into it? Or alternatively, how do I compile the C++ code into the .NET EXE so it runs within a managed environment? Note that it wasn't designed for this and may misbehave if I attempt to change too much.

• The main problem is interfacing with it. How do I expose some C++ classes to be accessed from .NET? I know exactly which classes I need and I'll need only a couple dozen classes along with their relevant methods/properties to be available from .NET. I don't mind handwriting wrapper classes in .NET to help the .NET VM understand the class structure of the bytes transferred back and forth. I'm hoping I can directly work with C++ objects from a managed environment so most of my code can remain in .NET.

• Even if I run it as an independant app, would I have to resort to sockets or something to communicate with it? This is the absolute worse case and I'll do anything to avoid this.

Any help or pointers are appreciated, I hope I made myself and my task at hand clear and that my questions are specific enough and answerable. Thanks for any help!

Edit: If I write wrapper classes or generate them, can I use P/Invoke to create class instances and call methods on them and have them run native C++ code in the background? Where will the memory for such C++ objects be stored and managed? Within the .NET heap or outside it?

Windbreak

possible duplicate of Interface from a C DLL to .NET – Repartition

@Repartition C DLL to .NET is more straightforward. The answer is almost always P/Invoke + recreate your C structs in .NET using the attributes that you can throw on .NET structs. C++ to .NET can be more complicated because unmanaged objects could get involved – Cavernous

Answer 1

You can write managed C++ (C++/CLI) wrapper to unmanaged C++ code. It would be the most flexible solution. Basically, you write a .NET assembly in C++, the assembly exposes managed classes which call your unmanaged code. Then you can reference this assembly from your C# projects.

There is a very basic article how to do that: http://www.windowsdevcenter.com/pub/a/dotnet/2004/03/29/mcpp_part3.html

This might be helpful as well: http://www.multicoreconsulting.co.uk/blog/c-snippets/how-to-call-unmanaged-cplusplus-from-csharp/

And MSDN article .NET Programming in Visual C++.

Surrounding

Is your method the same as this? codeproject.com/Articles/14180/… – Windbreak

Not really, a good sample of "real life" managed wrapper could be mpg123 library (considering that you must be familiar with sound processing:). If you download the sources, there is one in ports\MSVC++\2008clr folder. – Surrounding

@Geotarget, the actual C++ code performance will not be affected, it will still be running in "unmanaged mode". But your managed C++/CLI classes, prefaced with ref or __gc keyword, will be processed by CLR with garbace collector and stuff. So, if you consume unmanaged C++ classes in your managed wrapper, you take the responsibility to release unmanaged memory pointers in its destructor/finalizer. – Surrounding

As a result of compilation you can get 2 DLLs: managed CLR assembly, which will consume unmanaged library. Both will run in their scope. – Surrounding

Thanks for your comments. Is your answer the same as Option 1 in Pete's answer? – Windbreak

Yes it is. Regarding his option 2: it would be much useful if the C++ project exposed its API through C-style Dinamic Link Library. DllImportAttribute would be much more effective in that case (in the meaning of dev time). But it also depends on how many structures you had to adjust layouts and marshaling for;) – Surrounding

Answer 2

Option 1

If you intend to use unmanaged C++ objects, it is probably better to write a managed wrapper in C++/CLI that has the same interface as the class that it's wrapping, but has a managed constructor and destructor to clean up the unmanaged resources. In C++/CLI you create unmanaged objects just like C++ that you have to delete yourself, or you can create managed objects with the gcnew keyword. The .NET facing side of the wrapper would take managed objects. The Native facing side of the wrapper could operate on all of the unmanaged data types that you already have.

For example, consider the unmanaged class Frobber. In C++/CLI, you would create a class called ManagedFrobber that would have all of the same methods as Frobber and contains a private instance of a Frobber. In the ManagedFrobber constructor, you would create your private Frobber instance. In the ManagedFrobber destructor, you would delete your private Frobber instance. Every method in your managed wrapper class would simply call methods on the private Frobber instance.

Option 2

If all you intend to call from the C++ world are c-style functions (static in the C# sense I guess), then P/Invoke is probably the way to go because then you don't have to worry about all of the nuances of a wrapper class. For example, if you pass an array from the Managed world into the Unmanaged world using a wrapper class, you have to worry about things like pinning the array in place so it doesn't get moved around by the .NET runtime while the managed world is messing around with it. With P/Invoke most of these nuances are handled for you.

Cavernous

With Option 1, would the C++ code still run at full speed? Or would it run inside a managed environment and be compiled to CIL which would be significantly slower than raw C++? Of course the performance hit using wrappers would be negligible, I'm just concerned about the actual C++ code. And how would the C++ code be compiled? Would it be stored as regular x86 assembly inside the DLL and the wrappers as CIL objects? Or would everything become CIL objects? – Windbreak

@Geotarget Writing a wrapper class would not involve recompiling the unmanaged C++. You would reference your existing compiled code and using the relevant headers. When you're done, you would have your original unmanaged binaries, a C++/CLI DLL containing your wrapper classes referencing the original binaries, and your C# executable that references your C++/CLI DLL – Cavernous