We have an existing MFC application created with VS 6. We recently upgraded to VS 2003 and were able to migrate our application so that it builds and runs using VS 2003 instead of VS 6. For upcoming enhancements, I would like to use some of the new features found in the .NET Framework classes, especially the xml-related features. This immediately leads to the Mixed DLL Loading Problem discussed in several KB articles.
I want to add some functions that use the XmlTextReader class into one of my existing dlls. My understanding is that I need to follow the instructions in KB article #814472 PRB: Linker Warnings... because my existing dll will be including some managed code, making it a mixed DLL. The overall application contains several MFC-based dlls for which the following config settings exist: UseMFC in a Shared DLL, Not Using ATL.
For now, I only want to use the new .NET classes in one of the existing dlls, for now, so I am starting with the assumption that the config settings discussed in 814472 mainly apply to this one dll, not all of the dlls. Is that correct
The initial instructions, to set Use Managed Extensions=yes, link msvcrt.dll, remove nochkclr.obj and link in the CRT, seem fairly straightforward. I made these changes and everything does build, but the application will not launch and the message says '..execption was thrown during process load'. Possibly that happens because I need to complete the remaining instructions.
However, the next section of instructions, about modifying the components that consume the dll, is less understandable. The dll i am modifying is entered by using DLL exports. The other dlls that call into this dll all contain legacy MFC native code, so I assume that they 'cannot use managed code', as the article says, but I'm not sure about that either.
It first says to modify my mixed dll by adding the functions DllEnsureInit and DllForceTerm. I'm not certain where to add these functions - in a new separate file (init.cpp ) or possibly in the existing file that also contains the DllMain function for this function
My main problem is this. Document 814472 seems to assume that the dlls are loaded dynamically, using LoadLibrary and FreeLibrary. This is not the case with our application - we seem to be using "load time dynamic loading", also called implicit loading, where all needed dlls are loaded immediately when the application launches. So, in sections 3 and 4, where it says to call DllEnsureInit before you use the dll for the first time, (and the opposite for DllForceTerm), I have no idea where to make these calls. The mixed dll will be loaded automatically when the application launches, so when do I call DllEnsureInit It's not obvious exactly when the dll will be used 'for the first time'.
I have searched alot of postings on various sites without finding any good discussions of this problem. Sorry if this seems elementary or obvious to you, or if I'm posting this in the wrong place - I have not had alot of experience with these types of problems. Any assistance would be welcome.
KB article 814472 Mixed Mode Loading Problem
kilis
First, it is hard for me to give good advices on how fix this problem because in most cases solution is very specific to your existing code. But I will try .
Correct, 814472 applies to a Dll that uses managed code, not to other DLLs that are not using .Net.
Correct, you are looking into the right section.
It does not matter much. You may do both ways.
Here I do not have good answer because this depends on how your code is structured. You need to find place where an function exported from Mixed DLL and which uses managed code is called first time, and call DLLEnsureInit() before this call. For example. you have function MyCLRFuncA() exported from Mixed DLL and it is called inside MyNativeFuncB() in EXE or DLL that consumes Mixed DLL. Add call to DLLEnsureInit() before the call to MyCLRFuncA() in MyNativeFuncB(). Same for termination. If a function MyCLRFuncC() is the last call into Mixed DLL during your application execution path, add a call to DLLEnsureTerm after the call to MyCLRFuncC().
Hope this helps,
Nikola
EmNat
Nikola,
Thanks, that is helpful and gives me a good starting point to try to get this working. I appreciate your taking the time to explain this.
Tom W.