Visual Studio Debugging Tip

I recently acquired a copy of "Debugging Microsoft .NET 2.0 Applications" by John Robbins.

Debbuging .Net apps is effectively what I do every day, and have done for several years. I consider myself fairly proficient at it (compared to most people around me, I have no illusions that I'm just a babe in swaddling clothes compared to the true gurus).

I bought the book spur of the moment, and almost regretted it between when the money went out of my account, and I started reading. Never fear, it's a fantastic read, full of tips and information brand new to me. Not just "Oh yeah, I've seen that tip before but never use it, maybe I should start", but brand new, hardcore debugging info. Today's post is part book recommendation, and part actual tip to convince you to buy a copy:

Make Object ID

Scenario: You're working in an ASP.Net application, pages have controls, controls have subcontrols etc, and somewhere along way the value of a variable is going haywire.

You add a watch on this.Foo within the control, and it displays the value fine, but as soon as you step back up the control stack, your watch is worthless.... wouldn't be fantastic if we could keep that watch valid without having to add watches to this.Control.Foo, this.SubControl.Control.Foo, this.Parent.Control.Foo etc depending on where you are in the control hierarchy???

Welcome to Make Object ID!

If you right-click on your watch when it's in a valid state (ie, displaying it's value), and choose Make Object ID from the context menu, you should see a little '{1#}' appear next to the value. This is this object's unique id within the debugger, available for you to use in different tool windows.

If you add a watch on the variable '1#', you should see the same value as the original variable (because it is the original variable). If you step back up (or down) the control hierarchy though, you'll see the watch remains valid, allowing you to monitor the variable from anywhere in the codebase...

Have fun!
Wokket