33

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?

jamie
  • 331
  • 1
  • 3
  • 3
  • 2
    Use multiple debugger instances. One for managed and one for unmanaged. Of course that means you'll have to attach and detach as the situation dictates. Of course, a strong battery of unit and integration tests a much better than whole app debugging in the first place. – Ritch Melton May 11 '11 at 00:29
  • 1
    @Ritch: The suggestion with the multiple debugger instances sounds very interesting. Would be worth a fullscaled answer imho. – Martin Ba May 11 '11 at 15:41
  • 1
    @Ritch: I think that often failing unit and esp. integration tests will then lead you to use the debugger to find out what went wrong exactly! – Martin Ba May 11 '11 at 15:42
  • @Martin This is how I did it in the past. It was an extremely large project, but it was fairly trivial to on which side of the fence the error was happening. – Ritch Melton May 11 '11 at 18:49

4 Answers4

42

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
Tae-Sung Shin
  • 20,215
  • 33
  • 138
  • 240
  • 2
    The "Allow unsafe code" was key for me, I had the "Enable unmanaged code" set but it would still always crash until I also added "Allow unsafe code". – David Sacks May 08 '14 at 19:36
  • 2
    I have a C# EXE (for UI) with legacy code in a native DLL and a "shim" C++ CLI DLL that I created to bridge the two. I had set breakpoints in the native code but the debugger didn't stop, even with "Enable unmanaged code" set. I did "Allow unsafe code" for the C# project, and set "Debugger Type" to "Mixed" in both my C++ CLI DLL and the native DLL (the code is in my solution) and voila - I stop at breakpoints in managed *and* native code! Yay! – rich p Apr 10 '15 at 14:25
8

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;

floyd73
  • 1,240
  • 9
  • 12
2

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...

roboto1986
  • 624
  • 2
  • 13
  • 28
2

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)

mahee96
  • 705
  • 6
  • 15