Deborah's Developer MindScape

         Tips and Techniques for Web and .NET developers.

April 29, 2010

ToString and the Visual Studio Debugger

Filed under: C#,Debugging,VB.NET @ 5:50 pm

It is always useful to override the ToString method on each your classes. This is especially true when using the Visual Studio debugger.

This example uses the list created in this prior post.

The list is returned from a function and the breakpoint is set immediately after  the return statement. Here is what the data tip looks like when hovering over the custList variable.

In C#:


In VB:


Notice how the items in the list show their index (0 through 3) in square braces and their class name in the curly braces. You can use the + to access the TreeView and see the property details for the class. But if you have lots of properties, you could be scrolling around to find the key bits of information you need.

You can change the information in the curly braces to contain more useful information by simply overriding the ToString method.

In C#:

public override string ToString()
    return this.CustomerId + " (" + this.LastName + ")";

In VB:

Public Overrides Function ToString() As String
    Return Me.CustomerId & " (" & Me.LastName + ")"
End Function

In this example, the most important pieces of information about the customer are the Id and last name. So that is what is returned from the ToString method. In your classes, you can return whatever information is useful for your debugging.

Now, when using the same debugging techniques described above, you can see the following when hovering over the custList variable:

In C#:


NOTE: For C#, this feature is available in VS 2008 and VS 2010.

In VB:


NOTE: For VB, this feature is new in VS 2010.

Now your most useful properties are displayed directly in the data tip. No need to navigate the property tree.

Override the ToString method on every business object to take advantage of this very useful debugging feature.



  1.   JohnS — April 30, 2010 @ 8:07 am    Reply

    Using ToString() is open to abuse by clients of your class.

    Better to use the DebuggerDisplay attribute to achieve the same result.

    See this post:

  2.   DeborahK — April 30, 2010 @ 10:17 am    Reply

    Hi John –
    Thanks for the tip. Can you give some more detail on the type of abuse you are referring to?
    Thanks again!

  3.   Rostov — May 6, 2010 @ 9:05 am    Reply

    I almost always put a ‘ToString’ on my custom objects anyway — this way, diagnostic readouts or dumps out of lists can be done using a #DEBUG condition for containing extra information, like IDs, when I am testing, and then when I deploy a release, I display something more pertinent and without sensitive data.

    I’m also curious as to what abuse John is talking about: given the ‘precious time’ of a programmer, I’d rather create something that CAN be used more often, such as placing said objects into listboxes, comboboxes, etc — and have “short display” pieces of information retrieved that’s consistent throughout the application.

  4.   Reno — September 18, 2011 @ 7:12 pm    Reply

    Hats off to whoever wrote this up and peostd it.

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2020 Deborah's Developer MindScape   Provided by WPMU DEV -The WordPress Experts   Hosted by Microsoft MVPs