Intro

I've been in this business a long time now and know that I wouldn't have made it very far without a good debugging tool.  Visual Studio has a great debugger that has saved the day for me as a developer many times over the years.  The tips in this article are a few I've discovered and learned over the years and I hope you find them helpful as well.

Tip 1 - Turn on 'Break when an exception is thrown'

Sometimes an exception occurs and breaks in the debugger but it's not the location from which the exception was initially thrown.  The debugger breaks at the first place the code handles it (in the catch block.)  But if the exception was thrown in a method that the try block calls, you may not be able to determine what the problem is.  In this scenario, it is helpful to turn on 'break when an exception is thrown' for  "Common Language Runtime Exceptions".

-    Menu: Debug > Exceptions (Must be using C# profile to see this menu option)
-    Shortcut:  Ctrl+D, E
-    Check the ‘Thrown’ checkbox for Common Language Runtime Exceptions

Tip 2 - Use two instances of Visual Studio to debug

Most of the time, using the Visual Studio debugger will do the job.  But there are some special scenarios worth mentioning where it is required to use another instance of Visual Studio to debug an issue.  I've used it in the following scenarios (I'm sure there are more):
-    Debugging a custom control when it is dropped on the designer - if there is an exception in your custom control that
     surfaces only when it is dropped on the designer, this is invaluable.
-    Debugging the ASPNET worker process (e.g. web services)
-    Debugging any assembly from another project that isn’t in your solution

Steps to do this:

1.    Open project/solution that has the code to debug
2.    Attach to the process you’d like to debug
       a.    Devenv.exe for another instance of visual studio (this would be the one that initiates the exception)
       b.    ASPNET_WP.EXE for worker process
       c.    Menu: “Debug > Attach to Process” or “Tools > Attach to Process”
       d.    Shortcut:  Ctrl+Alt+P
3.    Set breakpoints
4.    Turn on “Break when an exception is thrown” (see Tip 1)
5.    Do the thing that causes the exception (e.g. drop control on designer)
       a.    Hopefully, the debugger will break in your second instance at this point

Tip 3 - The DebuggerDisplay attribute

This tip may not save the day like the previous two, however, it will save a lot of time in debugging things like lists and arrays of objects that are alike but have different values.

Let's say you are trying to debug a list of phone numbers and know the one it is failing on but don't know where in the list it is.  This can be a challenge when the list gets long and looks like the following:

In the past, I've overridden the ToString() method to print out the phone number (or pick your properties for your class).  This may not be an option if the code actually uses the ToString() method for your class.  Thankfully, starting in .NET Framework 2.0, you can use the DebuggerDisplay attribute on the class.  It is used to display whatever you would like when inspecting something in the debugger.  The attribute can be applied to the following:  class, structure, delegate, enumeration, field, property, assembly.

Decorate the Phone class as follows:

[DebuggerDisplay("({AreaCode, nq}) {Prefix, nq}-{LineNumber, nq}")]
public class Phone
{
    public string AreaCode { get; set; }
    public string Prefix { get; set; }
    public string LineNumber { get; set; }

Now, the debugger looks better when we inspect this list:

Conclusion

It is good to have debugging tools in your toolbox.  Especially when time is critical and the problem must be fixed.  For more in depth coverage of debugging in Visual Studio, see the Intertech class “Introduction to Programming Training” at the following link:   http://www.intertech.com/Courses/Course.aspx?CourseID=99440