托管c dll的加载程序锁定错误,静态链接到本机c lib

我有一个托管c dll,其中几个托管类反过来调用我已静态链接到dll的库中的本机c代码.但是,如果我尝试在dll上运行RegAsm.exe,该工具会正确报告“我们没有注册的类型”,但随后会挂起.我很确定这是一个 loader lock问题,当RegAsm尝试加载它时我的dll会挂起.我正在使用Visual Studio 2008,快递版.

让我感到困惑的是,在将本机代码放入dll时,一切正常,但在从库中静态链接时却没有.我知道这篇文章与this question类似,但我的dll中没有DllMain,我没有从DllMain运行MSIL代码的风险.另外,遵循在单个文件上设置/ clr的建议没有帮助.

使用/ NOENTRY编译dll会修复锁定问题,但会导致应用程序因类型初始值设定项而断开< Module>抛出异常异常,显然只是推荐使用.NET 2003.

我怀疑静态成员的初始化可能是一个可能的罪魁祸首,但为什么在我的静态库中编译成MSIL会超出我的范围.

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.

解决了这个问题,但很少有事情不清楚,我很好奇：

我注意到,当事情停止工作时,静态链接库中的头文件中添加了两个静态变量,如下所示：

// 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)

将初始化移动到.cpp文件(并将static更改为extern)可修复加载程序锁定.任何人都可以指出为什么初始化程序会被编译为MSIL？

在修复之前,如果我只是#included来自托管dll的头文件,那么一切正常.但是,如果我包含标题AND也链接到lib,事情就不起作用了.由于lib也在内部使用头,我最终得到了静态变量的两个实例吗？在任何情况下,为什么投诉运行MSIL代码？

虽然事情现在有效,但任何见解都会受到欢迎.