Simple Mixed ATL DLL Project Crash At Exit with VS.NET 2005

[samsonfr]

Hello,

I have read KB 814472 and the article "How To: Remove Dependency on
_vcclrit.h"
(http://msdn2.microsoft.com/en-us/lib...us,vs.80).aspx)
which confirmed that VS.NET 2005 don't need the "/noentry + MSVCRT.LIB
+ __DllMainCRTSta rtup@12 + __crt_dll_initi alize, and
__crt_dll_termi nate" fix anymore ...

I used the article "How to: Compile MFC and ATL Code with /clr"
(http://msdn2.microsoft.com/en-us/lib...US,VS.80).aspx)
as a guide to configure a mixed ATL DLL project.

The problem I have happens under Windows XP SP2, with a mixed ATL DLL
developped with VS.NET 2005 and VB6 SP4 as a COM client. I needed a DLL
that could be called from COM clients (VB6 and ASP) but that would also
have access to a .NET component. I decided to use a mixed ATL dll
(using the /clr switch).

The code works but it causes an Access violation when the COM client
closes.

It happens with attribute-based ATL or traditionnal ATL.

You can create a simple test case to reproduce the problem :

Mixed ATL DLL
1- Create a new ATL project in VS.NET (attribute-based or not)
2- Insert a new ATL Simple Object
3- Add a method named 'Test'
4- Use the /clr compiler switch to enable the use of .NET from that
DLL. Use the "How to: Compile MFC and ATL Code with /clr" article to
guide you
5- Compile the DLL
6- Manually register the DLL using regsvr32.exe as mixed DLL don't seem
to register automatically

COM client :
1- Create a new VB6 application
2- Reference you mixed ATL DLL
3- Write the code to create an instance and call the 'Test' method
4- Compile the application, close VB6 and run the compiled EXE.
5- An error should occur when closing it

The only way to make this crash go away is to add the /noentry +
MSVCRT.LIB + __DllMainCRTSta rtup@12 settings. But those are supposed to
be for the dealock problem under VS.NET / VS.NET 2003. It is supposed
to be irrelevant for VS.NET 2005 ... :-(

Note that my test case doesn't include a single managed line of code.
Removing the /clr switch removes the problem completely ...

Anybody can confirm they experiment the same problem using my test
case?

Somebody at Microsoft knows what I am missing ..?

Thanks!

Frederick Samson
COM / .NET Developer