No DllMain() in MfcAtl project?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I currently hunting a problem with a MixedMode dll, which used to work well,
until the .NET Framework 2.0 is installed on a machine. Since the, the dll
fail when loaded stating that there is a problem with the "LoaderLock" bug.
Thus, I made sure that the dll is initialized properly before any other call
into the dll is made. I also gave my dll a empty DllMain as it was proposed
by Microsoft.

BOOL WINAPI DllMain(HINSTANCE hModule, DWORD dwReason, LPVOID lpvReserved)
{
return TRUE;
}

Since then, I get a Linker error:

mfcs71d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in
TwStratus.obj
mfcs71d.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in
TwStratus.obj; second definition ignored

When I try to prevent linking with <mfcs71d.lib>, I get the following
undefined symbols:

LINK : error LNK2020: unresolved token (0A000110) atlTraceException
LINK : error LNK2020: unresolved token (0A000111) ?s_trace@CTrace@ATL@@2V12@A

I don't know how to go on. Can anyone help me?
If this is the wrong group for this problem, please let me know!

Thanks in advance

Ulrich
 
Hi Ulrich!
mfcs71d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in
TwStratus.obj
Click to expand...

Either you use MFC or not...
If you use MFC, then the MFC provides a DllMain.

If you don´t use the MFC, you can define your own DllMain (and must not
call any managed code).

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Hello Jochen,

thanks for your reply!
What does that mean to me:
- Is it OK to use MFC in a mixed-mode (managed and unmanaged code) dll with
respect to the loader-lock problem?
- Or does that mean, that is is not possible to build mixed-mode DLLs in
conjunction with MFC?

What I am observing is: When I link my DLL (a TWAIN driver) with
mfcs71d.lib, the calling application terminates without any error message
when making a first call into that dll. When I try to set a breakpoint at the
first line of the entry point function, Visual Studio terminates with an
internal error.

DLL and calling application is compiled with VS 2003 and .NET Framework 1.1,
but the .NET Framework 2.0 is also installed on the machine and I can see in
the debugger, that some .NET 2.0 dll are loaded by the calling application
during startup.

Thanks for any idea.

Ulrich
 
Hi Ulrich!
- Is it OK to use MFC in a mixed-mode (managed and unmanaged code) dll with
respect to the loader-lock problem?
Click to expand...

Normally it should be ok...

DLL and calling application is compiled with VS 2003 and .NET Framework 1.1,
but the .NET Framework 2.0 is also installed on the machine and I can see in
the debugger, that some .NET 2.0 dll are loaded by the calling application
during startup.
Click to expand...

This is not good....
It seems that the app is loading the .NET 2.0 framework into the
process. And your DLLs is using the version 1.1.
The main problem of .NET is, that it is not possible to load two
runtime-version into one process. So your DLL must be able to run with
the v2 of .NET.
And it seems that MFC7.1 had some problem in mixed-mode DLLs run against
v2.0 of the framework...

I will try to reproduce the problem; maybe I can give you more infos...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Hi Jochen,

thanks for the quick response.
Let me know if I can give you any more information.

Ulrich
 
In addition to Jochen's reply...
What I am observing is: When I link my DLL (a TWAIN driver) with
mfcs71d.lib, the calling application terminates without any error message
when making a first call into that dll. When I try to set a breakpoint at the
first line of the entry point function, Visual Studio terminates with an
internal error.

DLL and calling application is compiled with VS 2003 and .NET Framework 1.1,
but the .NET Framework 2.0 is also installed on the machine and I can see in
the debugger, that some .NET 2.0 dll are loaded by the calling application
during startup.
Click to expand...

Visual Studio 2003 (in managed or mixed debugger mode) cannot debug applications
that load CLR 2.0, internal error is a typical symptom of this problem.
If you want to debug the application with VS2003, configure it (the application)
to use CLR 1.1:

http://blogs.msdn.com/jmstall/archive/2005/12/05/VS2003_crashes_with_2005.aspx

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]
 
Hello Oleg,
Visual Studio 2003 (in managed or mixed debugger mode) cannot debug applications
that load CLR 2.0, internal error is a typical symptom of this problem.
Click to expand...

Thanks a lot! This is very helpful to me! I will try to configure my dll to
use the 1.1 framework.

Kind Regards

Ulrich
 
Hi Ulrich!
Thanks a lot! This is very helpful to me! I will try to configure my dll to
use the 1.1 framework.
Click to expand...

You can´t configure your DLL to use the v1.1!!!
You must configure the EXE to use v1.1!!! (which might be fail)


Of course, it is a very bad idea to create DLLs which only exposes
unmanaged functions and internaly uses dotNet...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Hello Jochen,
Of course, it is a very bad idea to create DLLs which only exposes
unmanaged functions and internaly uses dotNet...
Click to expand...

I'm afraid you are right, but we had no choice: We produce an imaging
device, our internal software is all .NET based and we have to provide a
TWAIN driver to allow the outer world to access our device.
And a TWAIN driver is nothing more than a simple dll with only one(!) native
C entry point.
All this worked fine until the .NET 2.0 framework was installed on a target
machine. And now, I have to figure out way out of this mess.

Thanks for your help and if you have any idea, let me know!

Greetings

Ulrich
 
Back
Top