使用本机C ++，托管c ++ cli和c＃解决方案在混合模式下进行调试

Question

我有一个多线程项目正在进行中，启动项目设置为运行我的UI的c＃项目。然后有一系列基础c ++本机项目通过托管C ++ / CLI项目连接到C＃。我在c＃启动项目中启用了“启用非托管调试”，当我尝试调试本机代码时，我能够达到我设置的断点。但是，在我尝试再次运行并尝试再次达到断点之后，它会挂起。例如，如果我有一个循环，我尝试在每次迭代中进入它，在第二次迭代后程序挂起并且我必须强制退出。我在Visual Studio 2010中工作。调试开始证明在这个速度下不太有用，有没有办法排除这个问题？

Answer 1

当我想调试本机代码以及C ++ / CLI时，我会这样做：

1. 在C＃应用程序中，检查“构建”选项卡中的Allow unsafe code和项目属性的“调试”选项卡中的Enable unmanaged code debugging。
2. 对于C ++ / CLI dll项目，在属性的“调试”选项卡中，将“调试器类型”设置为Mixed

Answer 2

我们在调试复杂的混合代码应用程序时也遇到了问题，并发现Visual Studio在这些情况下并不可靠。我的建议是：

• 如果您正在尝试调试一段本机代码，请尝试使用本机项目作为调试器启动应用程序。在项目设置下，“调试”选项卡将“调试器类型”设置为“混合”，对于我们这有时帮助（例如，本机项目可以是DLL，只需将主Exe设置为项目设置中的调试目标）;

• 使用WinDbg，您可以更可靠地调试托管/非托管混合代码应用程序;

Answer 3

当我尝试从托管进入非托管代码时，我遇到了同样的问题，所以相反，我摆脱了托管端的所有断点并执行了以下操作：

1）通过File-＆gt; Open-＆gt;文件（即我的source.cpp）打开您未管理的源文件

2）在那里设置一个断点

3）启动托管代码调试（播放按钮）

它应该直接打破你的非托管代码......至少它对我有用......

Answer 4

好的，这就是我解决问题的方式，

简短答案：

1. 设置Configuration_Properties-> Debugging-> Debugger_type：混合（.NET Framework） 对于您的两个项目

   a。纯本机项目（非托管C ++ exe使用了托管C ++ CLR dll导出的功能）

   b。 C ++ / CLI-CLR项目（托管的C ++ dll从纯托管的库导出函数 通过引用C＃.NET dll（已将C＃dll的引用添加到托管C ++ CLR项目的引用列表中）-该项目作为黑白非托管代码和托管代码的接口。

2. 为受管C ++ / CLI设置Configuration_Properties-> Advanced-> C ++ / CLI_Properties-> Common_Language_Runtime_Support：公共语言运行时支持（/ clr）和.NET_Target_Framework_Version：xxx（在受管C＃项目目标框架中指定） -充当界面的CLR项目。

长答案：

我试图构建一个插件DLL（C ++ Native dll），该DLL应该在使用MFC / Win32 API集的普通非托管环境（C ++ Native）下运行。首先，我尝试使用Win32Api UI元素（例如窗口，线程等），并且它成为设计UI的核心，因为VS2019不会为我提供设计编辑器，除非我将项目声明为MFC并引入不需要的MFC服务。 / p>

为了使我的UI开发更容易，

我创建了一个C＃dll（托管dLL-标准类库.NET Core项目），该文件使用针对“ .NET Framework 4.7.2”的“ Windows窗体”。

然后，我创建了另一个C ++ / CLI-CLR dll（托管dLL-使用非托管C ++代码但在托管环境clr.dll中运行的CLR项目）。该dll用作接口，使用外部“ C” __declspec（dllexport）从封装在C样式包装函数中的托管C＃代码中公开功能。

主项目/启动项目是一个纯本机C ++（exe）非托管应用程序，它使用了从C ++ / CLI-CLR托管接口项目导出的功能，该项目在内部公开了UI元素。

除非我为托管CLR C ++ dll手动加载.pdb并将强制启动的非托管C ++应用程序的调试器类型强制为Mixed（.NET Framework），否则调试不可用。