While developing code we spend so much time debugging it that every opportunity to optimize is inestimable.
One of such optimizations is stepping into a method. Yeah, poor F11 stuff. How many times have you found yourself in a situation where you wanted to step into a method, but yet had to go through executing some properties enlisted as parameters?
From the outset, two alternatives. One is to hit
F11, fall into a getter, hit Shift+F11, get back and repeat the chain until you
get to the right point. Another is to put a breakpoint in the method you need and hit F5.
When you ask if there is a third option, the answer would probably be: "take a look at DebuggerStepThrough, DebuggerHidden and DebuggerNonUserCode attributes but don't forget about DebuggerStepperBoundary and one little magic Visual Studio checkbox". Apparently there's no paucity of options for a single task out there [1].
But there is another alternative, believe you me! And it does not require besmearing the code with debug attributes.
Magic happens here.
You can use a VB macro that simulates a step into the C# code the editor caret is currently on, bypassing any other calls that have to be done [2]. So, assign the action to some nice shortcut (Ctrl+F11, anyone?) and have fun!
Yours truly just took the macro created by Jim Griesmer and slightly updated it. It looked a bit inconvenient that breakpoints waylaying you on the way would interrupt the debugger. Say, in the example above, if you want to step into WriteCustomer but already have a breakpoint in SomeOtherProperty getter, then the original macro still steps into the getter.
The updated one goes directly into the code you need, bypassing all other calls and all the breakpoints en route:
Sub StepIntoHere()
On Error GoTo Cleanup
Dim debugger As EnvDTE.Debugger = DTE.Debugger
If debugger Is Nothing Or debugger.CurrentMode <> dbgDebugMode.dbgBreakMode Then
Beep()
Exit Sub
End If
Dim method As String = SelectedMethod()
Dim myBreakpoints As EnvDTE.Breakpoints = debugger.Breakpoints.Add(method)
'If we have at least one bound breakpoint, go, otherwise just step into.
If myBreakpoints.Count > 0 Then
Dim mybp As EnvDTE.Breakpoint = myBreakpoints.Item(1)
If mybp.Children.Count > 0 Then
debugger.Go()
'If we hit an existing breakpoint, skip it.
While (debugger.BreakpointLastHit.Name <> mybp.Name)
debugger.Go()
End While
End If
Else
debugger.StepInto()
End If
Cleanup:
'Delete the breakpoints we created.
Dim bp As EnvDTE.Breakpoint
For Each bp In myBreakpoints
bp.Delete()
Next
End Sub
Function SelectedMethod()
Dim result As EnvDTE.TextSelection = DTE.ActiveWindow.Selection
If result.IsEmpty Then
result.WordLeft(False)
result.WordRight(True)
End If
result = DTE.ActiveWindow.Selection
SelectedMethod = result.Text
result = Nothing
End Function
VS 2008 SP1.
Here I have to backpedal and say that VS2008 SP1 has this functionality included into the Visual Studio debugger – check out the Step Into Specific option.
But the option has the same "flaw" as Jim's macro: if a breakpoint is set in an intermediate property or method, you'll drop there, instead of going directly to the specific method you've chosen to step into. I'm pretty sure this feature had all sorts of design meetings and there is a reason for not overstepping the breakpoints, but for my humble purposes it makes no harm.
Footnotes.
[1] - Do we really need all these attributes? Um, yes – and the magic Just My Code option if the key there. With the option turned off, DebuggerStepThrough would allow you to step into a method – if you put a breakpoint in – but DebuggerHidden wouldn't. DebuggerNonUserCode attribute just tells that the marked code is not "My Code". And for completeness, DebuggerStepperBoundary attribute is used as an escape from the effect of a DebuggerNonUserCode one when context switches are made on a thread. Eek.
[2] - Here Jim Griesmer talks about writing your own Step Info Specific.