今天使用C++/CLI封装一个native dll 其中使用了BOOST 库,编译过程完全没有问题，但是在.NET程序中加载时出现了0x800700C1的异常，出错信息是该DLL或该DLL的依赖项不是有效的Win32应用程序。而native dll是在正式产品中使用的，绝对没有问题。经过一番查找，发现是由于该dll引用了boost::thread造成的，随便编写一个使用boost::thread的dll，使用c++/cli封装后，加载就会出错。经过google，发现一下信息：
I found out what causes the problem (which doesn't mean though that I have an idea how to solve it) and can now provide a reproducable test case. You must have installed Boost 1.34.1 (see http://www.boost.org/) and add this code to a C++/CLI project: Including the header boost/thread/mutex.hpp makes it impossible to load the DLL (yes, including is enough - no need to use any code from that header). I probably have to submit a bug report to Boost (or Microsoft?). Boris
文中提到包含了Boost库1.34.1版本中的mutex.hpp造成了该错误的发生，而我的dll也引用了boost中的thread库，boost版本为1.43，是否该错误在1.43版本中依然存在呢。由于跨平台原因，该dll无法改用windows多线程接口，因此不能去掉对boost.thread库的引用。继续搜索发现如下信息：
http://stackoverflow.com/questions/5670248/boost-mutex-c-cli-problems
The problem is that boost.thread uses some
#pragma sectiondirectives that are incompatible when built without /clr then statically linked to code that uses /clr.I've heard that rebuilding boost.thread with /clr (i.e., pass
cxxflags="/clr"when invoking bjam) fixes the issue, but I haven't tried it personally.I assume that dynamically linking to boost.thread (rather than statically, which is the default for VC++;
#define BOOST_THREAD_DYN_LINKbefore including any boost headers) should work too, but again, I haven't tried it.If that doesn't work, try googling for some combination of
boostthreadclrtls; you should find quite a few posts on the boost mailing list about it, as this is an old problem.
该回复中提到由于boost.thread使用了#pragma section指令，而导致其在静态链接时无法与/clr编译选项兼容。曾经有人使用/clr重新编译了boost.thread库修复了该问题，但是回复的作者自己并没有尝试。
现在问题清楚了，将dll改用动态链接boost.thread库后（定义BOOST_THREAD_USE_DLL)，问题解决了。
而后在boost库的开发网站上找到了该问题的说明：
https://svn.boost.org/trac/boost/ticket/3561
文中提到由于TLS问题，静态链接boost.thread库并不支持/clr选项，而该问题被标记为关闭，原因是"wontfix"。所以在/clr编译时只能使用boost.thread的动态链接库。