views:

293

answers:

2

I have a native c++ app, and I want to use some managed types that are in a separate managed dll. I believe that one way to do this and still keep the c++ app totally native is to use COM interop with .NET. However my problem is that my app has to initially run on machines that don't have the CLR installed, so I don't want the CLR to be loaded unless I actually make use of the codepath that calls into the managed DLL.

How can I delay load the managed DLL?

A: 

I would suggest making a COM callable wrapper for the managed component.

You can have your own .NET class with an interface that can be referenced by unmanaged code (in my case I had Classic ASP instantiating an object that was built with .NET).

Mayo
+1  A: 

I think the best way to achieve this is via COM interop, native to managed in this case. If you're app is native it wont't load the CLR by default. You can "delay load" the CLR by creating a COM object which is defined in the managed assembly only when it's actually required. The COM layer of the CLR will take care of loading the CLR at that point and returning a CCW to the managed object.

JaredPar
I tried this, but in order to use COM interop, you need to compile with /clr:oldSyntax, and just doing that *alone* causes the CLR to be loaded, *without* even actually calling any COM interop > managed DLL code. Does this sound like the correct behavior?
Leeks and Leaks
@Leaks, it shouldn't. If you export the TLB from your managed assembly and register it you should be able to create the object just like any other COM object. It should be indistinguishable in native code from any other COM object.
JaredPar
You're right, however the TechNet article I read on how to import the assembly TLB said I had to have the /clr:oldSyntax flag set in the compiler. This turned out to be completely false.
Leeks and Leaks