是否可以通过托管C++/CLI项目正常运行非托管C++？

Question

我正在使用C++/CLI包装一个纯粹的非托管VC++ 9项目,以便从.NET应用程序中清楚地使用它.我知道如何编写包装器,并且可以从.NET执行非托管代码,但我无法完全理解:

非托管lib是一个非常复杂的C++库,它使用了很多内联和其他功能,因此我无法将其编译为带/clr标记的托管DLL.我需要使用普通的VC++编译器将其编译为单独的DLL.
如何从此非托管代码导出符号,以便可以从C++/CLI项目中使用它？我是否将每个我需要的课程标记为可见extern？它是那么简单还是有一些更复杂的东西？
如何从C++/CLI项目访问导出的符号？我是否只包含非托管源代码的头文件,C++链接器是否会从非托管DLL中获取实际代码？或者,我是否必须在指向DLL中的类的新头文件中手动编写一组单独的"extern"类？
当我的C++/CLI项目创建非托管类时,非托管代码是否会在正常的VC9运行时运行得很好,还是会被迫在.NET中运行？导致更多兼容性问题？
C++项目创建了大量实例,并且有自己的自定义垃圾收集器,全部用纯C++编写,它是一个DirectX声音渲染器并管理大量的DirectX对象.所有这些都能正常工作还是会以任何方式影响Win32功能？

Answer 1

您可以从普通的本机C++项目(从十多年前从Visual Studio 6.0导入)开始,当您今天构建它时,它将链接到VC运行时的当前版本.

然后,您可以向其添加单个新foo.cpp文件,但配置该文件以使其启用/ CLR标志.这将导致编译器从该文件生成IL,并且还链接一些额外的支持,导致.NET框架在启动时加载到进程中,因此它可以JIT编译然后执行IL.

应用程序的其余部分仍然像以前一样本地编译,并且完全不受影响.

事实上,即使是"纯粹的"CLR应用程序也是混合应用程序,因为CLR本身(显然)是本机代码.混合C++/CLI应用程序只是通过允许您添加更多本机代码来扩展这一点,该代码与一些CLR托管代码共享该过程.它们在整个过程中共存.

如果您foo.h使用声明创建标头:

void bar(int a, int b);

您可以在本机代码或foo.cppCLR代码中自由实现或调用它.编译器/链接器组合负责所有事情.从CLR代码中调用本机代码不需要做任何特殊操作.

您可能会遇到有关不兼容的开关的编译错误:

所有这些更改只需要在特定的/ CLR启用的文件上进行.