Best Practice for Converting MFC Dlls to CLI/C++

[dan@6noels.com]

Our company has a large legacy application that we would like to
convert to run under the CLR.

The application consists of a large collection of Dlls that have been
written in C++ and MFC over the last 10 years. We would like to
develop some standards and become aware of the best practices for
managing the DllMain() problem.

I am familiar with Microsoft's document on this subject:

http://msdn.microsoft.com/en-us/library/ms173266(vs.80).aspx

Given the trouble of the loader lock problem, it would seem preferable
to delete Dllmain routines entirely rather than surrounding the
routines with "pragma unmanaged" directives. If a DllMain is very
simple, can I simply remove it?

MFC Extension Dlls however have a Dllmain that calls the method
AfxInitExtensio nModule(). Is there someway that I could build this DLL
in /CLR mode without a DllMain()? How would the extension Dll
initialize itself under managed code?

Thanks,

Dan

[Sheng Jiang[MVP]]

Re: Best Practice for Converting MFC Dlls to CLI/C++

Write managed wrapper classes around your MFC classes. See Hosting of MFC
MDI Applications from Within WinForms and WPF Applications
(http://www.codeproject.com/KB/miscctrl/HostMFC.aspx)

<dan@6noels.com wrote in message
news:16e1436d-67a9-425d-a623-bd85aee22bd3@y2 1g2000hsf.googl egroups.com...

Our company has a large legacy application that we would like to
convert to run under the CLR.
>
The application consists of a large collection of Dlls that have been
written in C++ and MFC over the last 10 years. We would like to
develop some standards and become aware of the best practices for
managing the DllMain() problem.
>
I am familiar with Microsoft's document on this subject:
>

http://msdn.microsoft.com/en-us/library/ms173266(vs.80).aspx

>
Given the trouble of the loader lock problem, it would seem preferable
to delete Dllmain routines entirely rather than surrounding the
routines with "pragma unmanaged" directives. If a DllMain is very
simple, can I simply remove it?
>
MFC Extension Dlls however have a Dllmain that calls the method
AfxInitExtensio nModule(). Is there someway that I could build this DLL
in /CLR mode without a DllMain()? How would the extension Dll
initialize itself under managed code?
>
Thanks,
>
Dan
>

[Ben Voigt [C++ MVP]]

Re: Best Practice for Converting MFC Dlls to CLI/C++

dan@6noels.com wrote:

Our company has a large legacy application that we would like to
convert to run under the CLR.
>
The application consists of a large collection of Dlls that have been
written in C++ and MFC over the last 10 years. We would like to
develop some standards and become aware of the best practices for
managing the DllMain() problem.
>
I am familiar with Microsoft's document on this subject:
>

http://msdn.microsoft.com/en-us/library/ms173266(vs.80).aspx

>
Given the trouble of the loader lock problem, it would seem preferable
to delete Dllmain routines entirely rather than surrounding the
routines with "pragma unmanaged" directives. If a DllMain is very
simple, can I simply remove it?

How could we possibly know that? Something that is "very simple" could also
be "very important".

>
MFC Extension Dlls however have a Dllmain that calls the method
AfxInitExtensio nModule(). Is there someway that I could build this DLL
in /CLR mode without a DllMain()? How would the extension Dll
initialize itself under managed code?

use #pragma unmanaged, better yet put DllMain in its own file that is
compiled without /clr to help make sure you aren't using any managed code.

Since AfxInitExtensio nModule is unmanaged the loader lock problems with
managed code and JIT don't apply. You already know it's designed for use
from DllMain, so it doesn't have any native loader lock problems. So go
ahead and call it as usual.

>
Thanks,
>
Dan