Once we are done with debugging something, perhaps not deleting the breakpoints and start to debug something else, it happens to get stuck with those "old" breakpoints. First reflex is to hit F5 so flow can continue, only until that happens enough times so we actually remove them. At least for me that's a bit annoying and counter productive.
Perhaps we just Disable all breakpoints? Fine, works well, but it happens that you keep doing it until the point you enable them again to get some back and end up having several breakpoints you really don't need at that point. Here starts that annoying behavior again.
Last option would be to delete all breakpoints when you start debugging something else. However, at some point you'll wish you had those breakpoints, especially those Conditional breakpoints or When hit/ Run macro, because you are back looking at that portion of the system once more.
But wait! Who said that was the last option?
This is when the Import and Export breakpoints for Visual Studio has its best use. You can read a lot about "handing off a debugging session to another developer" as the main reason to use it, and for sure it's valid but I believe the most common reason to use this would be to organize your own debug sessions.
My objective here is not to describe how to import and export breakpoints, this is very straight forward and you can check it here. I'd like to point out that as we have these t-sql scripts saved, to make our lives easier when troubleshooting database related issues, saving your breakpoints can save you a lot of time when debugging code.
This is mostly useful when working with huge applications, with many source files that are part of your debugging but are not part of the solution you have loaded with Visual Studio. Once you have imported your breakpoints, you can easily open any file by double clicking the breakpoint on Breakpoint window (CTRL + D, B).
If you don't organize your debug sessions by importing and exporting breakpoints, give it a try!
