从 Visual C++ 调用 C# 代码

基本上我需要从 Visual C++ 代码调用 C# 代码。 在阅读了大量有关可能方法的文章后，我决定使用 C++/CLI 机制。

最初我决定在 C++ 本机代码（dll 库项目）中使用一些函数，它们将调用 CLR 项目中的一些函数，CLR 项目将调用 C# 项目中的一些函数。

之后我想也许我可以摆脱桥梁项目（CLR 项目），因为它只会过渡到托管世界。我认为我可以创建我的本机项目，然后向其中添加一个 C++ 源文件，并且可以仅为该文件而不是整个项目启用 CLR 支持。 因此，这意味着我的本机项目将仅包含一个可以使用 C++/CLI 语法并代表 Bridge 的文件。所有其他文件只是本机 C++ 源文件。 从设计的角度来看这是正确的吗？

为了执行上述操作，我想我必须将托管 C# dll 文件添加到 C++ 本机 dll 文件的附加 #using 目录属性中。 问题是我不知道如何根据当前配置设置 C# dll 调试或发布版本的路径。

我还知道我无法将本机 C++ DLL 添加到 C# 项目引用中。 但看起来我可以在本机 C++ 项目中添加 C# dll 作为引用。怎么会 ？！这还管用吗？！ 如果我可以将 C# dll 添加到本机 C++ 项目引用中，我是否需要设置这些 #using 目录？！

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

执行此操作与通过选择 CLR 项目模板开始并没有明显的区别。无论哪种方式，结果都是混合模式.NET 程序集，其中包含 MSIL 和本机代码。在项目级别执行此操作只是为项目中的 .cpp 文件设置 /clr 的默认值。您还可以使用 CLR 项目模板来执行此操作，方法是覆盖单个 .cpp 文件的设置，现在禁用 /clr。最终的结果都是一样的。

我想我必须将托管 C# dll 文件添加到其他 #using 目录

是的，这是一种方法。也解决了您的查询，您可以在路径名中使用 $(Configuration) 宏。在编译时解析为“调试”或“发布”，具体取决于您构建的配置。我要强调的是，这实际上是没有必要的。编译器仅使用 C# 程序集中的元数据。只是声明。与 .h 文件完全相同，请注意您很少根据配置使 #include 不同。唯一的极端情况是当你使用#if DEBUG在 C# 源代码中包含/排除代码，这并不常见。

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

每个 VS 版本都对此进行了修改，不能 100% 确定你在做什么。当您添加引用时，实际上很少发生，它只是让编译器驱动程序添加/FU 编译选项 https://msdn.microsoft.com/en-us/library/81ex1b0a.aspx。如果 .cpp 文件不是使用 /clr 编译的，那么它什么也不做，编译器只是完全忽略它。当你使用时它确实会大声抱怨#using在源代码中并且没有使用/clr。否则两者之间没有真正的区别，只是更容易使用 /FU 控制文件的路径。

因为它只会过渡到托管世界

这里需要注意一点，还有很多事情正在发生。您在这里所做的称为“反向 pinvoke”，即本机代码调用托管代码。 C++/CLI 主要是为了做相反的事情而设计的。它更复杂，需要发生的重要事情是 CLR 需要在第一次调用时加载并初始化。这都是自动的，由您使用时自动生成的存根提供__declspec(dllexport)。 Robert Giesecke 的“非托管导出”实用程序所依赖的魔力相同，这是您应该考虑的另一个选项。

但它是有限的。您不能公开对象模型，而只能公开简单的函数。函数调用会增加开销，尽管它相当有限。而最大的问题是，你无法轻易诊断错误。 CLR 和大多数 C# 代码都希望调用者知道如何处理异常。问题是您不是来自本机 C++ 代码。你有some使用余地__try/__except但您无法获得有关异常的任何详细信息。这会将非常简单的问题（例如 FileNotFoundException）变成完全无法诊断的崩溃。您可以通过将调试器类型设置为“混合”来对其进行调试，但在发布后您将无法执行任何有用的操作。非常难看的支持电话。

实现相同目标而不会出现这些问题的其他方法是在 C# 库中使用 [ComVisible(true)]，从而允许在本机 C++ 代码中使用 #import。并通过其托管接口自行自定义托管 CLR，这是支持用托管代码编写的插件的程序所使用的方法。 AutoCAD 等 CAD 程序就是很好的例子。和视觉工作室。