Creating a C# DLL and using it from unmanaged C++

Question

I have a native (unmanaged) C++ application (using wxWidgets for what it's worth). I'm considering a separate tool application to be written in C# which would contain winform-based dialogs. putting some of those dialogs in a separate DLL would be useful as I'd hope to be able to use them from my C++ app.

But I have no idea how much messing about is needed to accomplish this, is it particularly easy?

EDIT:

I don't need to call dialogs functions directly. I just need a way for my C++ app to call an API in the C# DLL in order to pass data, and a way for the C# DLL to call methods on some kind of observer/back object in the C++ app.

e.g from C++:

CSharpManager *pCSM = SomehowGetPointerToCSharpObject();
CSharpObserver pCSO = new CSharpObserver;

pCSM->RegisterCPlusPlusObserver(pCSO);
pCSM->LaunchDialog();

As the user does stuff in the C# dialog, pCSO methods are called to pass data back into C++

So it's pretty much a raw C++/C# communication question, I think. But though I know C++ and C# I don't know how .net itself works. I know COM but would really rather avoid it, I doubt any other developers I work with know it.

Answer 1

It depends on what you mean by "I'd hope to be able to use them from my C++ app."

In the native world, a dialog has a dialog template structure and you can "cook" this into your executable, be it DLL or EXE. Fine. But in the managed world, things are a little different. There is no "dialog template" resource type for Winforms applications. Instead, forms are just code.

However:

• You can always CALL INTO a managed DLL from unmanaged code. This is trivial. That managed DLL can display your Winforms dialogs. So the native C++ portion of your app can invoke those dialogs. But it can't instantiate them directly without some additional work.

• You can always insert a C++/CLI "shim DLL" between your native C++ code and your managed DLL. Within C++/CLI, you can load both managed and .NET resources/dialogs transparently.

• For that matter, you can call .NET methods directly from native code, without an intermediary C++/CLI shim DLL, though it's a little messy.

But as for using the ".NET/Winforms dialog resource" directly...no. Not in the sense of using the same dialog template for both Winforms as well as native C++.

Answer 2

The lingua franca of interop in unmanaged code is COM. That's very easy to get going on the C# side, just use the [ComVisible] attribute. You'll need to write COM code in your C++ program to use it, not so easy to get going if you've never done that. Start with the #import directive if you use the MSVC compiler.

Your next option is to host the CLR in your unmanaged code yourself rather than relying on the COM interop layer to take care of it. It allows you to create managed types directly. This requires COM as well, but only to get the CLR loaded and initialized. This project shows the approach.

Answer 3

Links to descriptions of native exports from pure managed code, as requested by nobugz:

• http://www.codeproject.com/KB/dotnet/DllExporter.aspx
• http://www.csharphelp.com/archives3/archive500.html
• http://www.codeproject.com/KB/dotnet/DllExport.aspx?msg=2657379
• http://www.codeproject.com/kb/dotnet/emilio_managed_unmanaged.aspx

Answer 4

Either use COM, or write a C++/CLI wrapper that calls your C# dialog, then call this C++/CLI wrapper from your unmanaged C++ code.

Answer 5

I know there are a few answers here, but none of them point to a working example. When I ran into this problem I was able to figure out thanks to this example.

http://support.microsoft.com/kb/828736

Answer 6

I was going to post this as a comment to an earlier post, but since you've not accepted any answers yet maybe it'll be the one you're looking for.

Your original post had one question: "is it particularly easy?" The answer to that is an emphatic no, as evidenced by the answers you're getting.

If the other suggestions (native exports/COM/etc) are "way over your head" (your words!), and you're not going to be able to dive in and learn, my suggestion would be that you need to reconsider your proposed architecture.

Why not write the shared functions in a C++ library, which can then more easily be used by your existing C++ application? As a general rule it's a lot easier to consume native components from managed code than vice versa - so writing your C# app to consume the shared C++ DLL would be a much easier job.

I realise this doesn't answer the original technical question, but perhaps it's a more pragmatic answer to the problem you're facing.