Manually Host CLR

  • Thread starter Thread starter MLM450
  • Start date Start date
M

MLM450

I need my unmanaged app to work with managed controls, but I can not
use the /clr option. I have read that the Common Language Runtime can
be "hosted manually" which eliminates the need to turn on the /clr
option. How is this done?
 
I need my unmanaged app to work with managed controls, but I can not
use the /clr option. I have read that the Common Language Runtime can
be "hosted manually" which eliminates the need to turn on the /clr
option. How is this done?
Click to expand...

I see that Jochen has already pointed you to links that explain how to load
and start the common language runtime (CLR).

Usually, once this is done, you invoke methods on managed classes. If those
methods are part of the framework, all is well. But if those methods are in
your classes there are two possibilities.

If those classes are written in C#, say, you already have CLR support. Again
all is well.

If they are written in C++ then either they are compiled with CLR support or
you use COM to access them.

The point I'm trying to make is that hosting the CLR is far from trivial.
There are good reasons for doing it (SQL server does it, ASP.Net does it, I
do it <g>). I'm just wondering why it is that you need to.

Regards,
Will
 
I need my unmanaged app to work with managed controls, but I can not
use the /clr option. I have read that the Common Language Runtime can
be "hosted manually" which eliminates the need to turn on the /clr
option. How is this done?
Click to expand...

You can create managed C++ assembly, which will export unmanaged entry
points to your managed stuff.
This way you can indirectly run CLR by calling exported functions.
 
Yep, I second William. Hosting the CLR should always be your last option! Do
it only if you've exhausted every other possibility.
 
Thanks for all the replies! I really appreciate it. Here's why I need
to avoid the /clr option.

I created a C# control that I need to use in our app. It is set up to
use CCW so I can make use of it in unmanaged code.

Until now, I have been testing my control with a temporary unmanaged
app (with /clr on) that is based on the example provided by this
article:
msdn.microsoft.com/msdnmag/issues/03/03/WindowsForms/default.aspx

Now I am trying to implement the control in our real product. It needs
to be used in an unmanaged DLL. I turned on the /clr option in the DLL
project and all seemed fine. But when I compiled the main app, it could
no longer see the "extern" functions in my DLL. From what I can tell,
it looks like the entire app would need to be compiled with the /clr
option. We can not do that right now, so I need to find a way to do
this without /clr.

BUT HERE IS A FOLLOW UP QUESTION:
I changed my testing app that was based on that MSDN article and
changed it by removing the #using lines (System, System.Windows.Forms,
MSCORLIB) and removed the /clr option. The app (dialog app) still works
but it crashes when I attempt to close the app. As it destroys the
window, the CCmdTarget destructor fails the "ASSERT(m_dwRef <=1)".
Perhaps if I resolve that I will be OK??
 
Now I am trying to implement the control in our real product. It needs
to be used in an unmanaged DLL. I turned on the /clr option in the DLL
project and all seemed fine. But when I compiled the main app, it could
no longer see the "extern" functions in my DLL. From what I can tell,
it looks like the entire app would need to be compiled with the /clr
option. We can not do that right now, so I need to find a way to do
this without /clr.
Click to expand...

I don't know why that should be. You can mix native and managed code in the
same library or application. In fact, you can do that within a module via

#pragma managed

and

#pragma unmanaged

When you see your application "can no longer see" the extern functions is it
that they are no longer exported?

Mixed-mode DLLs can be tricky when built with VS2003. This article explains
some of the pitfalls:

http://support.microsoft.com/?id=814472
BUT HERE IS A FOLLOW UP QUESTION:
I changed my testing app that was based on that MSDN article and
changed it by removing the #using lines (System, System.Windows.Forms,
MSCORLIB) and removed the /clr option. The app (dialog app) still works
but it crashes when I attempt to close the app. As it destroys the
window, the CCmdTarget destructor fails the "ASSERT(m_dwRef <=1)".
Perhaps if I resolve that I will be OK??
Click to expand...

Sorry, but I don't know much about MFC. If no one responds here you may want
to repost in an MFC group.

Regards,
Will
 
Thanks for the info. I had seen that article about mixed-mode DLLs. I
tried what it suggested and it did not help (unless I did something
wrong).

I wanted to see if that assert would fail in our real app, so I tried
adding the control without the #using statements or /clr. It wouldn't
compile, but the header file (can't locate it now) that had the compile
error also had comments about adding #import statement for
mscorlib.tlb, System.tlb, System.Drawing.tlb, and
System.Windows.Forms.tlb. I did that and it compiles with only a couple
warnings:
1) C4278: 'ReportEvent' in mscorlib.tlb is already a macro; use rename
2) C4192: Automatically excluding IDataObject from
System.Windows.Forms.tlb.

Do you think what I am doing is safe?
 
Thanks for the info.
Click to expand...

You are welcome.
I wanted to see if that assert would fail in our real app, so I tried
adding the control without the #using statements or /clr. It wouldn't
compile, ...
Click to expand...

Well, "it wouldn't compile" is not enough information for those of us who
are not clairvoyant. :-) In general, the posts that contain short snippets
of code and the exact text of the compiler diagnostic often get the most
replies.
Do you think what I am doing is safe?
Click to expand...

I don't know. In general, when you have to ask yourself that question you
are almost always already in the soup. It's trite to say, but it is always
best to stick to the trodden path and ask for help about a specific problem
when you need it.

Regards,
Will
 
Hi Will,

Thanks again for the response.

I didn't give details about the failed compile because I didn't
feel they were relevant to my main question. My question was more about
using the #import statements to get a .NET control to work in an
unmanaged app.

The reason why I am asking if it is safe is because of past experience.
I once posted how I solved a problem and someone responded that my
approach was probably not the correct solution. It seemed to work, but
if it is as easy as using #import, then why don't I see more people
recommending it? Perhaps there are drawbacks to this approach I have
not yet encountered?

I performed the failing compile again to see the errors. There were
hundreds of errors related to missing types like ISitePtr and
IContainerPtr. The errors make sense since I have no CLR in the app.
The errors are in the TLH and TLI files for my .NET control. At the top
of the TLH file are comments starting with "Cross-referenced type
libraries:" that listed the #imports I used to get the control
working. Now that I added the #imports and recompiled, the
"Cross-referenced type libraries:" lists nothing. I guess it adds
those comments to let you know what your app is lacking?

Thanks,
Mike
 
Back
Top