How to compile ATL module with CLR

[Guest]

Hi,

I've read the article at
http://msdn2.microsoft.com/en-us/library/ms235211.aspx
about how to compile MFC/ATL code, but I still have one question unanswered:

Should I have the
CComModule _Module;
definition and the
CInitInstance()
code compiled as manages or as unmanaged code?

Thanks for any help,
Genady

 

[Marcus Heege]

Hi,

I've read the article at
http://msdn2.microsoft.com/en-us/library/ms235211.aspx
about how to compile MFC/ATL code, but I still have one question
unanswered:

Should I have the
CComModule _Module;
definition and the
CInitInstance()
code compiled as manages or as unmanaged code?

Thanks for any help,
Genady

Here are some hints:

1) You should define _Module in a file compiled without /clr.
2) You should make sure that no managed code is executed during the
construction of _Module
3) You should not use #pragma unmanaged
4) You should not compile all your project files with /clr

Hope this helps

 

[Brian Muth]

I respectfully disagree with Marcus. It looks like you have some old VC6
code. I would upgrade the code to VC8 first before applying the steps as
outlined in the KB article.

Brian

 

[Marcus Heege]

I respectfully disagree with Marcus. It looks like you have some old VC6
code. I would upgrade the code to VC8 first before applying the steps as
outlined in the KB article.

Brian

Hi Brian,

maybe I am too jetlagged currently, but VC6 does not support /clr, so the
code must at least have been ported from VC6 to a higher VS version already.
Given that the question refers to an article of the VC8 documentation, I
assume it has been ported to VC8 already. However, I agree with you that if
the project is ported to VC7 or VC7.1, it should first be ported to VC8.

Respectfully, Marcus

 

[Marcus Heege]

Hi Genady,

Please tell us something more about your question, especially what version
of Visual C++ you are using.

This allows us to give you a more precise answer.

Thanks

 

[Brian Muth]

The OP talks about using _Module, which is part of ATL3 in VS6. VC8 uses
_AtlModule.

Brian.

 

[Marcus Heege]

Hi Brian,

The OP talks about using _Module, which is part of ATL3 in VS6. VC8 uses
_AtlModule.

Brian.

But VC8 still supports _Module and CComModule, so if the project is ported
from VC6 to VC8, it will likely use the old alternatives...

The only one who can tell us what the concrete situation is, is the original
poster, but it seems he doesn't care about us any more

Marcus

 

[Brian Muth]

B

 

[Guest]

Hi guys,

Thanks for your answers and I certainly do care (I took a day off yesterday,
and there is a time difference).
The code was originally written in VC6, later ported to VC7.1 and then to VC8.
We didn't change much of it, because it just worked.

Now we're considering the use of .Net in some of our modules, which raises
the question of how do we initialize the module properly.

I did try to compile the file that has _Module definition without /clr, but
I get an assertion in a call to "new CDynLinkLibrary(AFX_EXTENSION_MODULE
.....)";
The AFX_EXTENSION_MODULE constant is defined in the same file, and therefore
is should be initialized as unmanaged.

Now I'm not a COM/ATL expert, so I hope to hear your advice on how to make
the /clr introduction most smoothly.

Specifically - should the new CDynLinkLibrary(...) call be made from managed
or unmanaged code?
What about InitInstance()/ExitInstance() methods?

Thanks again for your help,
Genady

 

[Marcus Heege]

Can you reproduce the behavior in a simple project, created from a VC6
wizard, and ported to VS 2005?

I currently do not have VC6 available.

Another question: What files do you compile to native code and what files to
managed code.

Marcus

 

[Guest]

I'm afraid I can't reproduce it right now, since I also don't have VC6
installed.
Can you point me to instructions of upgrading ATL/MFC code to VC8? (is it
somewhere in MSDN?)

Following the instructions that I found on MSDN, I only compile stdafx.cpp
without /clr and the rest of the files are compiled with /clr. Of course
I escape the dll initialization functions with an #pragma unmanaged section.

I now got it work with few of our dlls (many other dlls remain native),
making the InitInstance() methods to compile as managed code. The
application starts fine, but I get problems at shutdown. Yet, I'm still not
sure whether what I did is right or just works by chance.
I'm not in the office right now (will be back only next week) so I can't
tell exactly was the error message is, but it is some kind of assertion in
the VC's own MFC/ATL code.

Thanks again,
Genady

 

[Marcus Heege]

I escape the dll initialization functions with an #pragma unmanaged
section.

Don't use #pragma unmanaged - functions that should be compiled to native
code should end up in files compiled without /clr

I now got it work with few of our dlls (many other dlls remain native),
making the InitInstance() methods to compile as managed code. The
application starts fine, but I get problems at shutdown.

Restart the whole VC8 -> VC8 with /clr process again. Do not compile any
existing file with /clr. Add a new emptry file compiled with /clr. Even
though it is empty it ensures that the linker creates a mixed code assembly.
Test this assembly regarding startup and shutdown issues. Add managed code
in the new file.

Yet, I'm still not
sure whether what I did is right or just works by chance.
I'm not in the office right now (will be back only next week) so I can't
tell exactly was the error message is, but it is some kind of assertion in
the VC's own MFC/ATL code.

Please send me the callstack you see when the assertion occurs. I would like
to use it for research purposes.

 

[Bruno van Dooren]

I escape the dll initialization functions with an #pragma unmanaged

Don't use #pragma unmanaged - functions that should be compiled to native
code should end up in files compiled without /clr

Hi Marcus,

You seem to be very adamant about not using #pragma unmanaged.
is there a specific reason, or side effects that are not obvious?
The only thing I can see against it would be readability and practical
problems with project maintenance.

kind regards,
Bruno.

 

[Marcus Heege]

Hi Marcus,

You seem to be very adamant about not using #pragma unmanaged.
is there a specific reason, or side effects that are not obvious?
The only thing I can see against it would be readability and practical
problems with project maintenance.

kind regards,
Bruno.

http://www.heege.net/blog/default.aspx#ad5e2c3da-ff4d-40bc-bea9-9da8ec9e091e