Robert Prouse at Alteridem Consulting has a great post about how you can make debugging easier with attributes, which I've used extensively with a few nice to have modifications to a framework I maintain.

It definitely makes debugging an object simpler because you can pick key information to be displayed when you debug an object. For example, by default, the description for an object is it's namespace. If you have a list of the same type of object, then you get the same description for each one. By adding a DebuggerDisplay() attribute, you can give more info about that object - we use the primary key info, and it makes it much simpler to pick out which object in the list you need to look at.

The other attribute I like is the DebuggerStepThrough attribute - being able to tag that on simple gets can really make debugging go faster. Imagine a method that takes 5 parameters, and you're passing in all simple properties of an object that the getter just returns a private field. If you're stepping into that method in debug mode, that saves something like 15 "F11"'s. Granted, I wouldn't take the time to add this to most of the code I write - but for a framework, it's nice to add some of those types of features when lots of people will be using them.

I'm also toying with the idea of adding DebuggerNonUserCode attributes to the methods in our framework code. This would mean that in most cases, when you debugged with code on top of the framework, you wouldn't step into the framework - it would just run - like the way it does when you debug code that uses .NET framework classes. For those that don't know, Visual Studio 2005 has a "Just My Code" feature that honors the DebuggerNonUserCode attributes, but that can be turned off in the options so you can still step into the code.

Again, these are nice to know about, but for most code, this is probably overkill. It's nice to have in frameworks though.