What are the benefits of using System.Diagnostics.Debugger.Break() over Attach to Process?

Question

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.

Answer 1

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.