debugging in mixed mode with native C++, managed c++ cli, and c# solution

Question

I have a multithreaded project im working on and the startup project is set to a c# project that runs my UI. Then there is a whole series of underlying c++ native projects which are connected to the C# by managed C++/CLI projects. I've enabled in the c# start up project 'Enable Unmanaged debug' and when I attempt to debug the native code, I am able to hit break points I set. However, it hangs after I try to run it again and try to hit a break point again. For example, if I have a loop I try to hit inside it in each iteration, after the second iteration the program hangs and I have to force quit. Im working in Visual Studio 2010. Debugging beginning to prove not too useful at this rate, is there any way to preclude this problem?

Solution 1

When I want to debug native code as well as C++/CLI, I do following:

1. In C# application, check Allow unsafe code in Build tab and Enable unmanaged code debugging in Debug tab of project properties.
2. For C++/CLI dll project, In Debugging tab of properties, set Debugger Type to Mixed

Solution 2

We also had problems debugging complex mixed code applications and found out that the Visual Studio is not that reliable in these situations. My suggestions would be to:

• If you're trying to debug a piece of native code try to use a native project as the debugger start-up application. Under the project settings, "Debugging" tab set the "Debugger Type" to "Mixed", for us this helped sometimes (the native project can be a DLL for example, simply set your main Exe as debugging target in the project settings);

• Use WinDbg, with it you can debug both managed/unmanaged mixed code applications much more reliably;

Solution 3

I had the same problem when I tried to step into un-managed code from managed, so instead, I got rid of all the breakpoints on the managed side and did the following:

1) open your un-managed source file via File->Open->File (i.e my source.cpp)

2) set a breakpoint there

3) start your managed code debugging (Play button)

It should break directly into your un-managed code... at least it works for me...

Solution 4

Okay, here it goes how I resolved it,

Short Answer:

1. Set Configuration_Properties->Debugging->Debugger_type: Mixed(.NET Framework) for both of your projects

   a. Purely Native project (un-managed C++ exe consumes the exported functions from managed C++ CLR dll)

   b. C++/CLI - CLR project (managed C++ dll exports functions from a purely managed C# .NET dll by referencing(Reference to the C# dll is already added to the references list of managed C++ CLR project)) - This project as as an interface b/w unmanaged and managed code.

2. Set Configuration_Properties->Advanced->C++/CLI_Properties->Common_Language_Runtime_Support: Common Language Runtime Support (/clr) and .NET_Target_Framework_Version: x.x.x (as specified in the managed C# project Target Framework) for the managed C++/CLI - CLR project that acts as the interface.

Long Answer:

I was trying to build a plugin DLL(C++ Native dll) which is supposed to run under plain un-managed environment(C++ Native) which uses MFC/Win32 API sets. First I tried to go with Win32Api UI elements such as windows, threads, etc and it became hardcore for designing the UI, since VS2019 doesn't give me the design editor unless I declare the project as MFC and bring in unwanted MFC services.

To make things easier for my UI development,

I created a C# dll(managed dLL - Standard Class library .NET Core project) which uses "Windows Forms" targeting .NET framework 4.7.2

Then I created another C++/CLI - CLR dll(managed dLL - CLR project which uses unmanaged C++ code but runs in a managed environment clr.dll). This dll acts as an interface which exposes the functions from the managed C# code wrapped in a C style wrapper function using extern "C" __declspec(dllexport)

The main/startup project was a Pure Native C++ (exe) unmanaged Application that consumes the functions exported from the C++/CLI - CLR managed interface project which internally exposes the UI elements.

Debugging was not available unless I manually loaded the .pdb for the managed CLR C++ dll and Forced the Debugger type of the startup unmanaged C++ application to Mixed(.NET Framework)

View more solutions