问从visual C++调用C++代码

EN

我可以只为该文件而不是整个项目启用CLR支持。

通过选择CLR项目模板，这样做和开始工作之间没有有效的区别。无论哪种方式，结果都是一个混合模式的.NET程序集，包含MSIL和本机代码.在项目级别上这样做仅仅是为项目中的/clr文件设置.cpp的默认值。还可以通过重写单个.cpp文件(现在禁用/clr )的设置来使用CLR项目模板来完成此操作。最终的结果是一样的。

我认为我必须使用目录将托管的C# dll文件添加到其他#

是的，这是一种方法。也可以解决您的查询，您可以在路径名称中使用$(配置)宏。根据您构建的配置，在编译时解析为"Debug“或"Release”。我要强调，这其实是不必要的。编译器只使用C#程序集中的元数据。只是声明而已。与.h文件完全等价，请注意，您很少根据配置使#包含不同的内容。唯一的角落是当您在#if DEBUG源代码中使用C#来包含/排除代码时，这种情况并不常见。

但看起来我可以在本机C#项目中添加一个C++ dll作为引用。

这已经在每一个VS版本中进行了修改，而不是100%确定你在做什么。在实践中，添加引用时很少发生，它只是让编译器驱动程序添加/FU编译选项。如果.cpp文件不是用/clr编译的，那么它什么也不做，编译器就会完全忽略它。当您在源代码中使用#using而不使用/clr时，它确实会大声抱怨。两者之间没有真正的区别，只是更容易用/FU控制文件的路径。

因为它只向管理的世界过渡

在这里，谨慎一点是恰当的，还有更多的事情要做。您在这里所做的工作称为“反向调用”，即调用托管代码的本机代码。C++/CLI主要是为了做完全相反的设计。更复杂的是，需要发生的重要事情是，在第一次调用时需要加载和初始化CLR。这都是自动生成的，它是由一个存根提供的，当您使用__declspec(dllexport)时，存根是自动生成的。罗伯特·吉塞克( Robert )的“非管理出口”实用程序所依赖的魔力与此相同，这也是你应该考虑的另一个选项。

但它是有限的。您不能公开一个对象模型，只是简单的函数。函数调用中增加了额外的开销，尽管这是相当适度的。最大的问题是，你不能轻易地诊断错误。CLR和大多数C#代码都希望调用方知道如何处理异常。问题是，您不来自本机C++代码。您在使用__try/__except方面有一定的回旋余地，但无法获得有关异常的任何详细信息。这将非常简单的问题，如FileNotFoundException，变成完全不可诊断的崩溃。您可以通过将调试器类型设置为“混合”来调试它，但是在发送它之后，您不能做任何有用的事情。非常丑陋的电话支持。

在没有这些问题的情况下实现相同目标的其他方法是在ComVisible库中使用C# (True)，允许在本地C++代码中导入#C++。和自定义托管CLR自己通过它的主机接口，这种方法使用的程序类型，支持插件编写的托管代码。像AutoCAD这样的计算机辅助设计程序就是很好的例子。还有。

我怀疑你是否可以拥有整个项目的非CLI，并在其中只制作一个文件的CLI功能。总的来说，这种方法相当棘手。

我建议考虑使用DllExportAttribute：https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports导出您的DllExportAttribute：https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports函数

试试ILASM 2.0 https://msdn.microsoft.com/tr-tr/library/496e4ekx(v=vs.110).aspx

基本上，工作与C++/CLI中的导出相同。

// unmexports.il
// Compile with : ilasm unmexports.il /dll
.assembly extern mscorlib { auto }
.assembly UnmExports {}
.module UnmExports.dll
.method public static void Bar()
{
  .export [1] as bar
  ldstr "Hello from managed function"
  call void [mscorlib]System.Console::WriteLine(string)
  ret
}

注意:您可以使用ILDASM解压缩C#和C++/CLI来查看如何导出它。(如本例所示)