I have a class that looks like this:
public class MyService
{
private MyService(){}
public static string GetStuff()
{
var stuffDid = new
I had this happen in a 1 project out of 25 which were all in the same solution. The other projects honored breakpoints but this 1 didn't. I removed the project from the solution (delete, not unload) which broke all references to it and then added it back to the solution and that worked!
If that doesn't work you may want to recreate the problem project from scratch and add that new project to the solution.
The best explanation I have for why this worked apart from pure luck is that we migrated projects from one version of VS to another many, many times over the years and maybe one of those migrations caused this problem.
To debug step-by-step, you must do two things. First you must set the break point, then you must attach the debugger to the process running your code. If you are running IIS Express and you have 64 bit machine, then you need to attach iisexpress.exe that is running your code. If you press CTRL + ALT + P, you'll get to the attach to process window. After attaching, the break point should be hit if the code matches.
Some ideas.
Debugger.Break()
in your code instead of a breakpoint
in VSHave you been adjusting the date on your computer at all? This can really screw up a build process. If so, delete all your obj/bin folders manually and recompile.
I have a very specific scenario that resulted in the apparent issue of "Breakpoint not being hit".
Since no other answers here mentioned it, I will add mine in the chance that it will help someone who had the same issue.
The solution, in my case, was silly, and with as much LINQ as I use I should have figured this out sooner. When running a method that returns an IEnumerable, where the return statements contained within are actually yield return
statements, then that method will not be executed when you call it.
It will actually be executed when you call another method from that IEnumerable object, such as ToList()
or Count()
. Only then will the method be executed and the breakpoint reached.
VS behaves exactly the way you described (not hitting the breakpoints, hitting the code you're not expecting to hit when stepping through) when it uses .pdb file which was generated using the source code somehow different from the code which is used upon debugging. I can't guarantee that this is your case, but I've observed such behaviour many times when I needed to step into the code which was supplied as a pre-built library which was generated against an older/different code with same filenames/symbols.
Silly me the Test Project wasn't set to be built: