Visual Studio 断点警告

Question

When debugging my code, I often throw breakpoints in to check the values of local variables to make sure everything is on the right track.

Lately, when I make changes to my code and recompile, all my breakpoints turn into the outline of a circle (instead of a full red circle) and it gives me an error that reads;

The breakpoint will not currently be hit. No executable code is associated with this line. Possible causes include: conditional compilation or complier optimizations.

What's strange about this issue is that I can simply remove and add the breakpoint and everything will work completely fine.

I am not using any type of conditional compilation or complier optimizations. Does anyone know what this means or how to fix this? It gets quite annoying replacing 10-12 breakpoints each time I compile.

Answer 1

This can happen for a few reasons

• The code the debugger is using is different from the code that the application is running
• The pdb file that the debugger is using is different from the code that the application is running
• The code the application is running has been optimized and debug information has been stripped out.
• The code in which you have breakpoints on hasn't been loaded into the process yet (assuming the things above are not the culprits)
• If you are attaching the debugger, pay attention to what .net framework it's attaching to (i've had issues with it using .net 4 when code was all .net 2.0)
• The assembly you have is also in the GAC. This might happen if say you installed your program so you could debug it, but the installer put the dll in the GAC.
• Remove the reference and re-add it (thanks to forsvarir ). Typically this occurs when the project that is referenced is not in the solution, and VS will copy the dll from the bin directory of another project. You will know this was the issue when you try to re-add the reference, and can't find the project:)

It's pretty tough to figure out what's going on here, but i would suggest using the fusion log viewer to see what is being loaded and where it's being loaded from and then you can look at the dll and see if it's old code, etc.

Answer 2

Check the project settings

Make sure you don't check the code optimize option, and make sure debug symbols are checked.

Notice that when you change the configuration other settings might change as well and you might not see. Make sure the values are correct for the configuration you are attempting to compile.

---

Delete the output files

Physically delete all generated DLLs, PDBs and EXEs. Then compile again to generate the files. Sometimes Visual Studio can "get lost" and "forget" to overwrite the output files when you build your solution.

---

Restart your computer

It usually solves 99% of problems. I already had some issues with Visual Studio and restarting it or the computer solved the problem.

Answer 3

I know this is an old post but still timely enough as I was looking for any other reason I might be getting this problem.

That being said you also might want to check the "Temporary ASP.NET Files" in your c:\Windows\Microsoft.NET\[Frameworks] directories if you are creating a web application as these files are often the cause in my experience.

Answer 4

Adding this response to the old thread in case someone like me is tracking down this mystery in an older ASP.Net application. I had one Webform code-behind which did not respond to breakpoints with the "...no executable code..." debugger warning. It was doing my head in as all of the other pages were working fine. I'd done the clean, rebuild, purged the temporary ASP.Net files, no joy.

The culprit with this file was the inclusion of several #ExternalSource directives surrounding some of the member variable declarations. Once those were removed and the project rebuilt, the break point behavior was restored. Those ExternalSource lines were appearing in the generated section of the code-behind. Not sure why they were there.

Answer 5

The use of the precompiler directive #line appears to affect the breakpoints behavior as well, as I've just discovered.