I'm trying to debug a C# dll from a native C++ executable. I have a C# COM object that is loaded and run from native code via IDispatch. Everything is built in Debug, both C# and C++ code. Whilst I can see all the c++ code, and all the c++ dlls have their symbols loaded and available for debugging, breakpoints etc the C# code refuses to play.
What I do see is that the C# dlls all refuse to load their symbol pdbs, reporting "skipped loading symbols for ngen binary" in the modules window.
Incidentally, I am debugging the C# solution here, I have set the native executable as the 'start external program' in the COM project's debug settings.
Now I can start the C++ executable and then attach to it, and then all works as I expect - the symbols load and I can set breakpoints in the C#.
This is using Visual Studio 2013u4. Is there a setting to enable mixed-mode debugging? One niggle is that the native code was built with VS2010.
Here's the Module window - note all pdbs and dlls are in a single directory, you can see the c++ dlls loaded, but not the C# ones.
Here's the modules window - note the 3rd entry for the EvCom dll (the COM object) which I assume is the entry enabling debugging.
There is nothing of any interest in the Output window, when it comes to load the COM dll, I see the following (in the case of attach to running process, the other only has 2 Loaded lines instead of 3).
'Explorer.exe' (Win32): Loaded 'C:\Dev\...\lib\debug\EvCom.dll'.
'Explorer.exe' (Win32): Loaded 'C:\Dev\...\lib\debug\EvCom.dll'.
'Explorer.exe' (Win32): Unloaded 'C:\...\lib\debug\EvCom.dll'
'Explorer.exe' (Win32): Loaded 'C:\Dev\...\lib\debug\EvCom.dll'.
One thing of interest - I checked the "Use Managed Compatibility Mode" in the debug settings and, thought it still doesn't load my symbols when starting debugging, it only shows 1 entry in the modules list. This time saying "No native symbols in symbol file" for the C# dlls.
It looks like the problem is not being able to select the debugger type in VS2013 (or 2012). This connect article suggests its "by design" with some workarounds.
Turns out it is all down to the changes in debug engine for .NET 4.0
.NET 4 and greater uses a different debug engine than .net 3.5 and below, when you start debugging a native application the debugger will choose a .net debugger for you (defaults to .net 4.0) and if your .net dll is built using this platform, all will be well - breakpoints will be hit.
If your loaded dll is .net 3.5, then the debug engine will not understand the dlls that are loaded and will refuse to load symbols or debug.
The solutions are either to rebuild as .net 4, or start the native executable and attach to it (where you can select the debugger type, either 'old' .net or 'new' .net) or you can create a project from the executable and set its debug settings to specify the right debugger.
What I find annoying is that Microsoft could easily have started the debugger using the .NET framework type specified in the project you're debugging (after all, when debugging a dll and specifying an external program, you still want to debug the dll you're pressing F5 for, so you know what debugger to use!)(What is even more annoying is that once managed debugging is started in a loaded dll, you can then step into projects built using older .net frameworks without problem).
More details on this Microsoft connect article