Introduction

The good old problem: how to find a variable value during code execution? Debuggers with breakpoints and watch windows are great, but only if the program can be stopped in the right moment in the right spot. Unfortunately, conditions are not always that ideal and dumping needed values to a log file or console, for future analysis, is a more realistic option.

Another common scenario is a simple debugging or run-and-forget utility that needs to produce human readable output with minimal coding. Such a tool is not intended for non-technical users and beautification of the output is not a priority, yet time spent on producing useful output is.

In either of these cases, I often find myself writing code like:

Not only this is verbose and annoying to write, the first iteration of such code is often useless. Either the object being dumped does not override its ToString method, or output is confusing because of typos, or useful fields are not included, or exceptions are thrown, or multiple threads at a time execute the code and Debug.WriteLine output is mixed together. Things get even worse when there are anonymous objects, arrays, enumerations, lists, references to other objects (with loops) in the properties, that need to go to the log file as well.

There is a better way: a generic debug writer that uses reflection to display all object fields and properties, walks the object graph if necessary, and produces something human readable and with enough information for analysis. This is hardly a new idea, CodeProject already has an article on the topic, and some other solutions can be found on the Internet, but I wanted something more flexible, simple, generic and that is a single .cs file without any dependencies, so can be added to any project. And during development of XSharper framework/scripting languageDump class was created.

Using the Code

Include the Dump.cs file to your project, or link with complete XSharper.Core assembly. Now the buggy piece of dumping code above can be replaced with:

to produce:

Object ID and hash code go to the output as well, to simplify tracing of complex object graphs with loops. For example, /* #2, 01fed012 */ above means object #2 with GetHashCode()=0x01fed012.

Also it's possible to control depth of the dumped object tree, maximum number of array elements displayed and some other little things. See the source code and attached sample for details.

Special Types and Properties

Some classes have properties with side effects. For example, properties that take a long time to be retrieved or that invalidate internal state of the object. To prevent Dump from accessing such properties, the properties should be registered with Dump.AddHiddenProperty() static method.

In addition, some properties and types cause too much bloat when dumped normally:

• 'Bloat' types are types that are not important to the application being debugged. For example, System.Type, System.Reflection.Assembly and many other runtime classes have dozens of public internal properties that are of little use to most application developers.
• 'Bloat' properties silently create a copy of the parent object when accessed. One example of this design are Parent and Root properties of System.IO.DirectoryInfo class. W/o special treatment dumping new DirectoryInfo('C:') would produce an long tree of nested objects, as Root property of 'C:' returns a new copy of itself.

To avoid these problems, some known 'bloat' types and properties are written to dump using ToString() method, and display /* ToString */ in the output. Additional 'bloat' types and properties may be registered via Dump.AddBloatProperty() and Dump.AddBloatType() methods.

Project Classes Debug Menu Won't Display Dev C Online

It's a good idea to register all known special types/properties at the program startup, to avoid threading issues.

Another Example

Dump details about installed CDROM drives to console:

History

The latest version can be downloaded from Google code.

Project Classes Debug Menu Won't Display Dev C On Mac