tags:

views:

107

answers:

4

I find it useful to override ToString() on many of the simple DTO/POCO classes I write to show some good information when hovering over instances within the debugger.

Here is one example:

  public class IdValue< T >
  {
    public IdValue( int id, T value )
    {
      Id = id;
      Value = value;
    }

    public int Id { get; private set; }
    public T Value { get; private set; }

    public override string ToString()
    {
      return string.Format( "Id: {0} Value: {1}", Id, Value );
    }
  }

Is there a way in .NET to automatically have a ToString() override that lists out public properties or is there a good convention to follow?

A: 

This is not a good design consideration. I'd advice you to extract values where you need to log them or have a helper method (you can use extension methods on System.Object).

aloneguid
+8  A: 

You could override ToString in a base class then use reflection on the instance to discover the public properties of the derived class. But this will likely introduce performance problems in other areas of your code. Additionally, because ToString is used by a lot of things (String.Format, default data binding, etc.) overriding ToString for debugging purposes will make your classes less useful in other scenarios.

Instead, you may want to use the DebuggerDisplay attribute to control how the debugger shows hover tips and info in the watch window and such. I'm pretty sure this works if you apply it to a base class. You can also create custom visualizers but that's more involved. Check out this link for more info on enhancing the debugger display experience.

Enhancing Debugging

Josh Einstein
Thanks! All I had to do was add this attribute to the class I originally posted and it behaved the way I wanted:[DebuggerDisplay("Id: {Id} Value: {Value}")]
Rob Packwood
A: 

here A way that it MIGHT be done in a debugger friendly way

public override string ToString()
{
     stringBuilder sb = ... your usual string output
     AppendDebug(sb);
     return sb.Tostring();
}


[Conditional("DEBUG")]
private void AppendDebug(stringBuilder sb)
{
   sb.Append( ... debug - specific info )

}

The [Conditional] attribute is the key to your question.

No Refunds No Returns
ConditionalAttribute is really more intended for when you're exposing a method to another caller whose build config you don't know ahead of time. In this case you could achieve the same result without the call-site ambiguity using #if DEBUG. But it's a very useful and little-known attribute!
Josh Einstein
A: 

Listen to the folks who are warning you about performance and/or design considerations. You're tightly binding a behavior to suite a pretty limited need, when you could decouple your needs by using an extension or decorator.

Sean H