Using Visual Studio 2008, to start debugging depending on my mood, I’ll either attach to process and hit breakpoints that way or I’ll place System.Diagnostics.Debugger.Break() in a relevant place in the code and start debugging when it breaks at that point.
The latter being necessary sometimes I find!
Not talking about F5 –> running in debug mode for a second…
System.Diagnostics.Debugger.Break();
Questions:
Q) I’m curious as to the minor differences between each option?
Q) What are the benefits and drawbacks of using each?
I’ll start it off…
Debugger.Break() drawback =
forgetting about Debugger.Break()’s and leaving them in there!
Debugger.Break() benefit = Start debugging exactly where you want without hitting other unecessary breakpoints that may still be in the code which would be hit if attached to process.
Pre-empt the haters
I’ll just pre-empt the haters that will undoubtedly say if I’m using Debugger.Break() I’m not understanding the correct way of debugging.
I’m just trying to start a conversation here as I believe there are different ways of debugging depending on the circumstances.
I was once working on a plugin-based app that did a lot of things on startup. It would do the plugin discovery among many other things. I couldn’t run it directly from Visual Studio, so F5 wasn’t an option, but Attach to Debugger wasn’t an option either, because many times I would need to debug all that stuff happening at startup. I would never be able to catch it in time with Attach to process. Therefore, I just set Debugger.Break() exactly where I want.
Another example; I was writing a cmdlet for PowerShell. Those you don’t run in Visual Studio; you run them from the PowerShell command line. They are usually quick little applications, and there’s no way you’ll catch them in time with Attach to Process.