+3  A: 

You can do it in VS 2008 too. I'm sure there's many ways to do it, but one way is to right click on the red dot in the margin of an existing breakpoint & select condition..., then just give it a condition that evaluates to a bool and it will only break if that's true. The conditional statement should have access to anything that's in scope at the line where the breakpoint is set.

There's also other options in that context menu that allow you to filter what will cause a break (for example only certain threads), break based on the number of times the breakpoint has been hit, run macros when you hit the breakpoint, etc.

Alconja
When I right click the breakpoint all I see is: delete breakpoint, disable breakpoint.
Lucas McCoy
Hmmm... are you using the express edition maybe?
Alconja
yerp its missing from express
Sam Saffron
+1  A: 

The other way to do this is make your own conditions and use a call to:

System.Diagnostics.Debugger.Break();

While it may not be as sophisticated as the VS2010 way of setting breakpoints, you can get the same effect with minimal code overhead. Just remember to take that stuff out when you build release code.

Note: In VS2008 and VS2005, you can set a conditional breakpoint by setting a regular breakpoint (F9 or double click in gutter), and then right clicking on that breakpoint to set the "condition...". The ability to set conditional breakpoints is NOT available in the VS2008 Express Edition.

Relster
I deleted my answer due to the overlap, but you should mention that VS 2008 express has no built-in support for conditional break points.
Sam Saffron
@Sam Saffron, you should edit his answer to become the all encompassing answer.
Simucal
+8  A: 

Similar to @Relster I have a code snippet with the following

#if DEBUG
    if( node.Name == "Book" )
        System.Diagnostics.Debugger.Break();
#endif

Where node.Name == "Book" changes based on the condition I want to test for. the #if DEBUG wrapper makes sure the checks never make it to release code.

This is also a lot faster than using the conditional breakpoints in Visual Studio. When you use the built in conditional bp visual studio has to break into the app, pause all the threads, evaluate the expression and determine if it is true each time it hits the breakpoint. In a tight loop this can be the difference between near full execution performance and running at a crawl.

Paul Alexander
Up-vote for use of "#if DEBUG ... #endif" (I was going to make a comment on the accepted solution to this effect).
Alconja
I had to accept your answer because up the lack of updating in Relster's.
Lucas McCoy