都是visual studio 2010 BUG惹的祸

　　这两天项目在用C#调用C++编写的一些库时遇到一个很头痛的问题，用C++对DLL进行测试没有任何问题，可用C#进行调用时居然所有输出参数均未被改变，也就是输出没有任何输出，但返回值是正确的。同事调了两天，曾怀疑是函数调用约定问题，于是不断地在__cdecl和__stdcall的各种组合方式进行尝试，虽然明知道windows DLL使用的是__stdcall，但的确经过测试它不管用；后来实在不行，又创建了两个工程，写了几个简单的函数，再用C#调，却没有任何问题，而我们的工作代码却调用不成功；后来我还曾怀疑可能是inline函数的优化造成的问题，因为在DLL中导出的函数是__stdcall的，但接口函数里面只调用了一个函数，用的却是__cdec，有可能如果把导出函数直接替换成内层的函数，可能调用约定不正确(当然，这在理论上也不应成立的)，于是关掉了编译器对inline函数的优化，依然无效。

　　今天快要下班的时候也闲下来了，我就开始处理这个问题，于时就尝试在C++的接口函数里添加断点，看C++函数是否正确执行并正常返回，于是启用了C#工程Debugging中的“Enable unmanaged code debugging”选项，奇迹发生了，C++代码的断点触发了，函数正常执行并返回，并且原来与C#的输出接口也正常了，数据被正常导出到C#代码中。难道是这个选项解决的问题？想想是不应该的，这个只是调试优化选项，而且创建的其它的测试工程也不需要启用这项的。于是又取消该项，再测，果然恢复原来错误的状态；然后，我又从DEBUG配置切换到Release配置，存在着同样的问题，只有启用了“Enable unmanaged code debugging”程序才能正常运行。问题解决了，但是肯定不是正解，启用的选项中是启用对C++代码的调试功能的支持，不应该影响程序的正常执行，这应该是Visual Studio或CLR的一个BUG引起的。

　　在重构过程中还遇到一个有意思的问题：同事起的工程的名字不伦不类的，我给改了个名字security，于是生成security.dll，出现了一个奇怪的问题，明明我编译的DLL中导出了我要的函数，在C#中即怎么也找不到指定的函数，后来我把DllImport的DLL文件的参数使用绝对路径，问题就消失了，肯定是在DLL的搜索过程中先找到了一个security.dll，这里用的是那个文件而不是我的文件，所以没有找到我要的函数，再改个名就好了。在给动态链接库起名字的时候越规范、越标准越好，但随时都要注意别跟其它的系统文件重名了，否则就会出现这些“奇怪”的问题。