Scott Hanselman

The DebuggerDisplayAttribute in Visual Studio 2005 and IFormattable

February 04, 2005 Comment on this post [5] Posted in ASP.NET | Ruby | Bugs
Sponsored By

I didn't realize this when I did my generic IFormattableObject implementation last week, but this week finds me writing a chapter on Debugging for an ASP.NET 2.0 book.

I was checking out the DebuggerDisplayAttribute and realized that it uses a similar format string style as my stuff. (Of course, my stuff isn't new, languages like Ruby and others have done it for years).

Anyway, the point was that I had been wondering if my idea "fit" into the world of .NET, but the syntax of this DebuggerDisplay attribute left me feeling more justified for my work. It's interesting though, that they are offering this attribute, when I always used ToString to do the same basic thing in the debugger. So, in a Whidbey world of DebuggerDisplayAttribute, what's ToString() for? I guess just Console.WriteLine(myObject)?

UPDATE: The "TracePoint" syntax in the VS 2005 Debugger is the same.
For example: {i.FirstName} Function: $FUNCTION, Thread: $TID $TNAME
prints out the variable i's property FirstName as well as some psuedo-variables like the current function, the Thread ID and Thread Name

Syntax Description
  "{_forename} {_surname}")]
Uses the private _forename and _surname members
  "Employee- {ToString()}")]
The ToString method is called to provide the textual representation to be displayed as the value of the object
  ( {Forename} {(_wizard) ?
  \"Is a Wizard\" : \"Is 
  \"Is not a Wizard\" } )")]
An expression is evaluated in order to provide a differing representation to the user based on the value of a flag

Now playing: Kevin Lyttle - Turn Me On

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
February 04, 2005 23:21
The DebuggerDisplay attribute will for sure be very popular, but I wonder if it'll work with obfuscated code in the case of private members. Since you seem to be looking into this topic, have you tried that ? Maybe obfuscation tools will have to start checking and updating some of those attributes too.
February 04, 2005 23:55
I don't get your point. This attribute is for interactive debuggers only, in debug builds only. You wouldn't be interactively debugging an obfuscated debug build, so that would never come up.
February 05, 2005 0:07
I'm guessing the the DebuggerDisplayAttribute adds something to the assembly. Including the formatting strings like "{_forename}". I don't think Sergio was concerned about being able to debug a release assembly as much as he would prefer to hide or at least obfuscate the name of the field in the assembly...even in the formatting string.

If DebuggerDisplayAttribute emits nothing in the release build or only adds the information to the debugger information file (pdb), then there should be no problem. For example, if I loaded the release assembly in Reflector, I should not be able to find anything generated by the DebuggerDisplayAttribute in a release build.
February 05, 2005 4:59
I, for one, am extremely glad that there is now an attribute that will allow you to specify how your instances are shown in the debugger. I read a little on how to do this in VS2003, and it looks like you have to edit a text file somewhere in the program files tree. And you would have to do that on each machine. I'm glad that this made it in.

- Joshua
February 05, 2005 5:58
Andy, I was actually not concerned about the format string exposure. Maybe I understood the DebuggerDisplayAttribute incorrectly but I was thinking that if I put such attribute in one of my classes and release the assembly, then someone else using this release build and debugging his own code that uses one object of my class would be able to see the formatted text in the debugger windows, even without my debug build. If the DebuggerDisplayAttribute is only considered in the debug build, then my previous comment indeed made no sense. Sorry for the confusion, Scott.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.