VS2010 : Unable to Hit Breakpoints in Managed Code
In Visual Studio 2010, if you are debugging a native executable which in turn loads a managed DLL built against a version of the framework previous to version 4, you may find that breakpoints which are set in the managed code are not hit. The breakpoints are displayed correctly, you just never hit them when executing the code in question.
If you attach to the process as opposed to running it from the debugger directly, you can hit the breakpoints if you change the code type to Managed (v2.0, v1.1, v1.0) when attaching. This can be done in the Attach to Process dialog (from the Debug, Attach to Process... menu). From there, choose the Select button and choose the Managed (v2.0, v1.1, v1.0) selection in the Select Code Type dialog.
This is an issue in the Visual Studio 2010 debugger. When loading the managed code, the debugger makes the wrong assumption about your managed code and loads the incorrect managed debugger.
This can be worked around when debugging directly from Visual Studio by including an application configuration file for your native executable which causes the correct framework debugger to be loaded. E.g. :
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
From the Project menu, select Add New Item and then select the Configuration file in the Add New Item dialog. Copy the configuration code above into the config file.
Microsoft is investigating resolutions to this issue to be included in future releases of Visual Studio or Visual Studio Service Packs.
Comments
Anonymous
July 13, 2010
This bug just bit me today. I'm trying your suggested fix right now. Is there anywhere that I can monitor the status of this bug?Anonymous
December 05, 2010
Also, the "app.config" file needs to be named after the file you specify in the "start external program" textbox. So if I'm using Notepad and want to debug it the app.config should be named "notepad.exe.config"!!Anonymous
March 31, 2011
work around works tho!Anonymous
May 20, 2012
I have a C++ application which references a C# COM object dll. Both are targeted to .Net 4.0 but still the C# breakpoints are not hit with the error above. Note that this happens when running the Debug configuration and not when running the Release configuration. Using the suggestion above did not resolve the issue. Any tip for this situation?Anonymous
March 04, 2013
The comment has been removed