Using the DebuggerBrowsable Attribute

Visual Studio is very rich with debugging tools and we always use debug windows for troubleshooting issues.

Debug windows gives  us the access to view values of objects and option to edit the same. Lets say I’m working with an object, which is having large number of members in it. Now when I debug I required only few of them and the other member object values are not that much important for me. In this case I will be facing some difficulties to see the required member object in in the debug hierarchy. Which indirectly wasting my time.

To help us in this kind of situation .NET already have Diagnostic Debugger Attributes. In this post we will check the usability of DebuggerBrowsableAttribute.

DebuggerBrowsable Attribute determines if and how a member is displayed in the debugger variable windows. You can add the DebuggerBrowsable attribute to properties, fields and indexers in classes and structures.The constructor for this attribute takes one of the DebuggerBrowsableState enumeration values, which specifies one of the following states:

  • Never indicates that the member is not displayed in the data window. For example, using this value for the DebuggerBrowsableAttribute on a field removes the field from the hierarchy; the field is not displayed when you expand the enclosing type by clicking the plus sign (+) for the type instance.
  • Collapsed indicates that the member is displayed but not expanded by default. This is the default behavior.
  • RootHidden indicates that the member itself is not shown, but its constituent objects are displayed if it is an array or collection.

Let us understand more with a sample example,

The blow code block is used to understand different DebuggerBrowsableState of DebuggerBrowsableAttribute,

static void Main(string[] args)
{
 List employers = new List();
 employers.Add(new Employee
 {
 Id = 1,
 Name = new FullName("Dave", "A"),
 Phone = new List() { "732-751-2921", "732-751-2923" },
 UniqueNumber = System.Guid.NewGuid().ToString()
 });
 employers.Add(new Employee
 {
 Id = 2,
 Name = new FullName("Aydin", "B"),
 Phone = new List() { "732-752-2922", "732-752-2924" },
 UniqueNumber = System.Guid.NewGuid().ToString()
 });
 employers.Add(new Employee
 {
 Id = 3,
 Name = new FullName("John", "C"),
 Phone = new List() { "732-753-2923", "732-752-2932" },
 UniqueNumber = System.Guid.NewGuid().ToString()
 });
 employers.Add(new Employee
 {
 Id = 4,
 Name = new FullName("Peter", "D"),
 Phone = new List() { "732-754-2924", "732-752-3922" },
 UniqueNumber = System.Guid.NewGuid().ToString()
 });
}

Now let me show you the class definition,


class Employee
{
 public int Id { get; set; }

[DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
 public FullName Name { get; set; }

[DebuggerBrowsable(DebuggerBrowsableState.Collapsed)]
 public List Phone { get; set; }

public string UniqueNumber { get; set; }

[DebuggerBrowsable(DebuggerBrowsableState.Never)]
 public string Email { get; set; }

[DebuggerBrowsable(DebuggerBrowsableState.Never)]
 public string Fax { get; set; }

[DebuggerBrowsable(DebuggerBrowsableState.Never)]
 public int Age { get; set; }
}

public class FullName
{
 public FullName(string firstName, string lastName)
 {
 FirstName = firstName;
 LastName = lastName;
 }
 public string FirstName { get; set; }
 public string LastName { get; set; }
}

If you observe the above code you can see that I have decorated properties with DebuggerBrowsable attribute and desired DebuggerBrowsableState. In debug mode, you can check the Employees object to see the effect of this DebuggerBrowsableAttribute.

Below given screen shot shows the debug view of Employee object.Without DebuggerBrowsableAttribute Quick Watch
In the above screenshot we can see that Age, Email, Fax are not listed and FirstName, LastName are shown without root element. Below screenshot shows the Quick watch of employee object without the DebuggerBrowsableAttribute.

DebuggerBrowsableAttribute Quick Watch

Advertisements

2 thoughts on “Using the DebuggerBrowsable Attribute

  1. Now all we need is a revamp of using so that we can make public typedefs of other types so we can use sensible names for these attributes, names that aren’t taking up half the screen. Without manually using to rename each thing in each file. Using is weak. System.Diagnostics.DebuggerBrowsable* in general is a fugly mess of a namespace. Just look at your code samples. There are more attributes than code. So you trade off being able to read the code in order to be able to make sense of classes in the debugger? This could be drastically improved.

    • If we want to apply DebuggerBrowsableAttribute to all of the properties then of-course it will give a feeling of more attributes than the actual code. But when we use it only in the relevant place we won’t be having too many attributes in the code base.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s