Loader lock error with managed c++ dll, statically linked to a native c++ lib

I have a managed c++ dll with few managed classes that in turn call native c++ code in a library that I have statically linked to the dll. However, if I try to run RegAsm.exe on the dll, the tool correctly reports 'no types we registered' but then hangs. I'm very sure this is a loader lock problem and my dll hangs when RegAsm tries to load it. I'm using Visual Studio 2008, express edition.

What puzzles me that everything works fine when placing native code into the dll but not when statically linking it from the library. I'm aware that this post is similar to this question but I do not have DllMain in my dll, there is no risk of me running MSIL code from DllMain. Also, following the advice of setting /clr on individual files did not help.

Compiling the dll with /NOENTRY fixes the lock problem but causes the application to break with Type initializer for <Module> threw exception exception and is apparently only reccommended with .NET 2003.

I'm suspecting that initialization of static members could be a possible culprit but why would that be compiled to MSIL in my static lib is beyond me.

Just to clarify: although I have no need of running RegAsm.exe on the dll, I'm using it as a check for the loader lock problem. In reality I'm consuming the dll in a c# assembly that does implement few COM-visible classes - so I need to do COM registration on that one. At the end C# IDE crashes during registering for COM interop, reporting 'R6033 c++ runtime error: Attempt to use MSIL code from this assembly during native code initialization. This indicates a bug in your application. It is most开发者_开发知识库 likely the result of calling an MSIL-compiled (/clr) function from a native constructor or from DllMain.

Solved the issue but few things are unclear and I'm curious:

I noticed that two static variables were added to a header file in the statically-linked lib at the time things stopped to work, that looked like this:

// The whole header is forced to compile as native 
#pragma managed(push, off)
....
static const std::locale commaSeparator(std::locale::classic(), 
                                        new DecimalSeparator<char>(','));;
....
#pragma managed(pop)

Moving the initialization to a .cpp file (and changing static to extern) fixes the loader lock. Could anyone point to why would the initializer get compiled to MSIL at all?

Before the fix, if I only #included the header file from the managed dll, things worked fine. But if I includeed the header AND also linked to the lib, things didn't work. Since the lib also uses the header internally, did I end up with two instances of the static variable? In any case, why a complaint about running MSIL code?

Although things work now, any insight would be welcome.

---

Compiiler wraps user-defined DllMain with its own code, which is used to initialize runtime library and global variables (so that user-defined DllMain could run with global objects already created and could use standard library). Even if you don't have DllMain, there will be still compiler-generated one. With /NOENTRY you instruct linker to ignore it.

So, doing something in constructor of a static variable is effectively the same as doing that from DllMain, and it seems that is the case here.

---

The following page, (especially the Initializing Static Objects and Implementation in Headers sections) has the following to say:

Because the same header may be included both by a CPP files with /clr enabled and disabled, or a #include can be wrapped inside a #pragma unmanaged block, it is possible to have both MSIL and native versions of functions that provide implementations in headers.

and

In Visual C++ 2005, as a convenience for users dealing with loader lock, the linker will choose the native implementation over the managed when presented with both. ... However, there are two exceptions to this rule in this release due to two unresolved issues with the compiler:
...
- The call to an inline function is through a global static function pointer. This scenario is particularly notable because virtual functions are called through global function pointers.

When placing the static variable directly inside the managed dll (or when compiling with \clr, for that matter), loader lock is avoided since only initialization of native static variables occurs within DllMain. Any static variable compiled as native, however, will deadlock if executing MSIL code. In our case, MSIL is generated for a part of STL which is used by the constructor of the static object, due to the surprising linker behavior when presented with both native and MSIL implementation.

A solution would be to:

• Compile everything with /clr (not possible for us since we need to use the static lib)
• Make sure all #included 3rd party headers (STL) are preceded with #pragma unmanaged (way too complicated)

• Remove static variable initialization from headers (via external linkage)

  // Solved by replacing initialization in header file
  static const std::locale commaSeparator(...);
  // with 
  extern const std::locale commaSeparator;
  // and doing initialization in a cpp file