Combining native C++ dll and c# assembly into a single dll/assembly

Question

4.75/5 (4 votes)

See more:

Hi,

I have a simple native C++ dll (no clr/managed code at all) creating an AppDomain and loading an C#-assembly into it using COM-Interfaces supplied by ICorRuntimeHost. This works so far without any problem.

The question: Is it possible to link the C++ dll and the C# assembly into one single file? It would mean, this file must be callable by a clr-unaware app via Win32's LoadLibrary and must be a valid .net assembly at the same time.

CP

P.S.: For clarification, I do not want to do IJW-things like #pragma (un)managed or do COM-Interop. The way of invoking the assembly via CorBindToRuntimeEx->CreateDomain->CreateInstance stays the same. What should be changed is that I want to have a single dll- or assembly-file instead of two separate files.

Posted 9-Mar-11 21:54pm

CP@work

Updated 9-Mar-11 23:16pm

v2

Add a Solution

Comments

CS2011 10-Mar-11 4:29am

Haven't done anything like this in past.my 5+

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CP@work · Answer 1 · 2011-03-10T23:49:00

Found the solution:

- Create a netmodule version of the assembly
- Simply add this netmodule to linker's "Additional Dependencies" in your dll project file and compile
- Set correct "Platform Toolset" in "General Properties" when linking .NET2.0-Assembly with VS2010.

Examining the dll with PEBrowse tells that there is a new ".NET MetaData (2.0)"-section.
You can see beside the normal exports (of the dll with depends.exe) the .NET classes etc. with Redgate .NET Reflector.

The native-code part of the dll bootstraps a customized appdomain and loads now itself (which was already done by before) as assembly inside that appdomain. No more missing assemblies or mismatched versions, garantueed failsafe deployment...

Olivier Levrey · Answer 2 · 2011-03-09T22:56:00

Solution 1

Possible? I think it is (but not sure).
I think I saw a post about exporting native methods from C# but you can't do it in one step. You must first compile, then disassamble, edit the MSIL code in some way, then recompile... I don't remember exactly and I am not even sure of it!!
But even though it would be possible, it is not easy.

The best way to do a mixed code assembly is using C++/CLI.
With C++/CLI you can export both native and managed code.

You can do a wrapper that references the native C++ dll and the C# assembly. But you would then have 3 dlls.
If you want to have only 1 DLL. Then you would need to convert the codes from both projects into C++/CLI code.

Posted 9-Mar-11 22:56pm

Olivier Levrey

Comments

CP@work 10-Mar-11 5:05am

Thank you for your answer.

Of course, with C++/CLI, I could exactly implement what I intend to do, but it is not an option for my project, unfortunately.
The C++ dll is the bootstrapper for my managed appdomain, it's statically linked and has no references to mscoree (latebound via GetProcAddress).
As far as I know, with using C++/CLI, I loose these "must-have features" for my project.

Olivier Levrey 10-Mar-11 5:24am

I didn't understand what is the "must-have-feature" you need for your dll? And what is statically linked? Do you mean you want your main app to statically link against the C++ dll? If so, you can do it with a C++/CLI dll: since it will generate a .lib file you can use it from your native app. And since it is also a .NET assembly, you can reference it into your .NET app.
Did I miss something?

CP@work 10-Mar-11 5:39am

Statically linked means that I have linked the runtime library with /MT instead /MD option. I have to prevent to be dependent of an external msvcXXX.dll. It does not mean that my dll is statically linked to the app.

As using a C++/CLI would also reference the runtime library as /MD, I would be depending to an external dll with all implications. This is not an option. That means "must-have"...

Olivier Levrey 10-Mar-11 5:52am

You are right. MSDN states that combining /clr and /MT is not supported: http://msdn.microsoft.com/en-us/library/ffkc918h.aspx So I suppose what you want to do is not possible in your case.