Breakpoint not hooked up when debugging in VS.Net 2005

后端 未结 12 1405
庸人自扰
庸人自扰 2020-12-09 23:38

Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the

相关标签:
12条回答
  • 2020-12-10 00:07

    Maybe this suggestion might help:

    1. While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
    2. Look for your project's DLL, and check the Symbol Status for it.
    3. If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.

    I've found that it's sometimes necessary to:

    1. stop the debugger
    2. close the IDE
    3. close the hosting application
    4. nuke the obj and bin folders
    5. restart the IDE
    6. rebuild the project
    7. go through the Modules window again
    8. Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.

    Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.

    0 讨论(0)
  • 2020-12-10 00:08

    Is the build configuration set to Release?

    Do you have a reference to an external DLL where the breakpoint is set?

    0 讨论(0)
  • 2020-12-10 00:09

    Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?

    0 讨论(0)
  • 2020-12-10 00:12

    Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.

    0 讨论(0)
  • 2020-12-10 00:12

    In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.

    This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]

    0 讨论(0)
  • 2020-12-10 00:13

    Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?

    If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.

    Again, the above only applies to .NET + COM Interop DLLs.

    0 讨论(0)
提交回复
热议问题