views:

1587

answers:

12

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 running version and therefore there's a mismatch that causes the breakpoint to be disconnected.

Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.

Added Note: This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.

+1  A: 

In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.

Tom Ritter
Did that at the behest of MS and it didn't help.
ScottCher
+1  A: 

Is the build configuration set to Release?

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

Mike L
Its set to DEBUG and there are no external DLL's - they are all local projects.
ScottCher
A: 

AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.

Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.

ScottCher
A: 

Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).

Santiago Palladino
They are in the same folder.
ScottCher
+1  A: 

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.

j0rd4n
its .Net and I'm not creating a DLL project consumed by an external exe.
ScottCher
A: 

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.

Jurney
Nope, not post build steps.
ScottCher
A: 

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]

Liam Westley
These breakpoints most definately should be hit - disabling compiler optimisations has no impact.
ScottCher
+1  A: 

I've had a similar problem in the past.

It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.

Read the post here and the comments to resolve it.

Ash
This is not a ASP.Net project though it does have webservices (its a smartclient app). The breakpoints are, however, broken not just in the webservice side but in the exe and related dll's.
ScottCher
A: 

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?

Santiago Palladino
Nope, nothing like that in play here though you are coming up with some really good suggestions. 8)
ScottCher
A: 

Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?

Jurney
No breakpoints were working and it was as if the code had been compiled in RELEASE mode.
ScottCher
+5  A: 

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.

Esteban Brenes
Glad to hear it worked!
Esteban Brenes
+1  A: 

http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/

Hotspot
Interesting and useful but not what caused the problem I was seeing - IE8 hadn't been installed (don't even think it was available at the time). Still - good reference, thanks!
ScottCher