Visual Studio.NET 2005 has a really cool feature called debugger visualizers. When you are inspecting an object while debugging, there are times that the standard inspection of fields and properties of the debugger is not the best way to check if the internal state of the object is correct. For example, a DataSet is very difficult to debug, because the data is stored in a long hierarchy of objects. A debugger visualizer is a viewer of objects of a predetermined type that presents the object to the developer using a custom UI that helps debugging it.
The debugger visualizer executes on a different application domain than the application we’re debugging so to access the object being inspected the data needs to be sent from one application domain to the other application domain. This implies that the object we’re inspecting needs to be serializable or we need to create a serializable proxy in order to visualize it.
There are quite a few articles on the web about debugger visualizers so I will not enter in detail in the process of writing a visualizer, but I’ll explain the basics. As I explained before, the visualizer runs in a different application domain than the process we’re debugging. To communicate those application domains, an object that inherits from VisualizerObjectSource is created. The visualizer inherits from the DialogDebuggerVisualizer class and has to implement the Show method, showing a custom dialog. Before showing the dialog, the visualizer usually retrieves data requesting it to the VisualizerObjectSource using an intermediate object that implements the IVisualizerObjectProvider.
The main method of the VisualizerObjectSource is GetData, where the object being debugged should be sent through a stream. If the object being debugged is big, this could be a long operation so a thing that can be done is to send a simplified object in the GetData method, and when the user wants to see more detail of the simplified object, transfer a more data using the TransferData method.
A data structure is something that is better represented graphically so I spent some days writing a bunch of visualizers for all the .NET System.Collections.* classes. Here you have some pics of it:
I had to write a basic diagramming engine in order to get some nice results. Writing the diagramming engine was the funniest part. I wanted a lot of flexibility so I end up implementing absolute and relative element positioning, cascading styles, shape composition, expandable elements, automatic layout adjustment, zooming, etc. I think that the resulting object model was pretty good even if it isn’t a complete diagramming engine.
After some work with the debugger visualizers, a big limitation surfaces. You can only attach a visualizer to classes and not to interfaces. I think Microsoft should change this is the next version as this is severely limiting the power of the visualizers.
Also, it is a shame that the .NET framework doesn’t include more complex data structures like a Tree or a Graph. A visualizer for a Dictionary, a List or a Queue can be useful, but a visualizer for a Tree and a Graph is very very useful. Every developer has to code his own Tree and Graph, so creating a viewer for them will make the developers to use my implementation if they want to visualize it because of the limitation of the debugger visualizers, and that can’t be done in a lot of cases.
You can read more about the visualizer pack here:
You can take a look to the evaluation version here: