By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,354 Members | 1,042 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,354 IT Pros & Developers. It's quick & easy.

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

P: n/a

I have read KB 814472 and the article "How To: Remove Dependency on
which confirmed that VS.NET 2005 don't need the "/noentry + MSVCRT.LIB
+ __DllMainCRTStartup@12 + __crt_dll_initialize, and
__crt_dll_terminate" fix anymore ...

I used the article "How to: Compile MFC and ATL Code with /clr"
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

It happens with attribute-based ATL or traditionnal ATL.

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

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 + __DllMainCRTStartup@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

Somebody at Microsoft knows what I am missing ..?


Frederick Samson
COM / .NET Developer

Nov 17 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.