Dot Net Thoughts

September 15, 2007

Debugging – Data when you want it, how you want it.

Filed under: Debugging — dotnetthoughts @ 8:00 am
Tags: , , , , ,

One of the keys to debugging is being able to get fast access to the data you’re interested in. Anybody who has developed code for any length of time knows the pain of drilling down through objects in the watch window to find the one property that is buried seven layers deep. Fortunately, .Net gives us the ability to see summaries of object data when we are debugging. Two of the most useful features for creating and viewing these data summaries are theDebuggerDisplay attribute and Visualizers. Both of these add debugging capabilities to Visual Studio by allowing you to see subsets of data or reformatted data more easily.

To demonstrate how these work, I have created a quick-and-dirty application which you can download here. The solution contains three individual projects.

  • The Family project contains a simple data object which represents an individual family in a phone book application. The object contains a location to enter a last name and a phone number, as well as zero to many family members associated with it.
  • The FamilyVisualizer is an application we can use to visualize our code in a friendlier format than what .Net will be able to provide by default.
  • The FamilyApplication exists to load and process family data. In reality, we’ll just set a few breakpoints in this object and look at the results.

The first item we’ll take a look at is the DebuggerDisplay attribute. This is a very easy way to pull to the surface exactly what data you need to see in an object. If you look in the Family object, you will notice that the class is prefaced with this attribute:

[DebuggerDisplay("Last Name: {LastName}")]

When debugging code, this attribute will cause the last name of the user to be displayed when you hover over the variable. Note that you can still drill down into the object to see the child properties should you need.

The DebuggerDisplay attribute is quite flexible, and will allow you to drill down in the object model, as well. For example, the following code displays the first child, assuming he exists.

[DebuggerDisplay("Last Name: {LastName} First Member: {FamilyMembers[0]}")]

The DebuggerDisplay is helpful from the standpoint of getting at data, but it isn’t so helpful in letting us visualize all of our individual family members. Since the FamilyMember property is one-to-many, we need a better way to display the individuals. This is where a custom visualizer comes in.

A custom visualizer is simply an object that extends the DialogDebuggerVisualizer and overrides the Show method. This allows you to use pretty much anything you can dream of to display data. If you look at the FamilyVisualizerDebuggerSide object in the sample code, you’ll note a couple of different things.

  • The class is marked with a DebuggerVisualizer attribute. This attribute contains information about what class is going to be used to present the visualizer (the FamilyVisualizerDebuggerSide), the type of object the visualizer is intended to display (the Family object), and a description for the debugger (Family Visualizer)
  • The project contains a form which we will use to customize our debugging display. It simply accepts data, and loads it into the appropriate labels and list boxes.
  • The class overrides the Show method, which will be used to display the debugger when debugging. Note that you must use windowService.ShowDialog to display the debugging form. (Calling familyForm.Show doesn’t work.)

If I copy my FamilyVisualizer dll into /MyDocuments/Visual Studio 2005/Visualizers and restart studio, I’m now able to access my visualizer directly from code that I have set a breakpoint on.


Selecting the visualizer displays the windows form which we created to show our family data.


If you want help creating you own visualizer, Microsoft has a very good Visualizer Walkthrough you can use.

 There you have it. a couple of handy tricks in a nut shell. Good luck and code safe!


Blog at