I thought I should wrap up my posts about the generic heap sample that I put together with a quick look through a few of the minor but interesting points it raised for me.

CLS Compliance

As the class has only generic interfaces, it can't be marked as CLS compliant, and also isn't visible to COM. If I'd chosen to implement ICollection as well as ICollection<T>, as the BCL collections do, then I could have had the benefit of both worlds.

Debugger Display Attribute

I implementd a really simple debugger display attribute.
[DebuggerDisplay("Count = {Count}, Head = {Peek()}")]
I've got used to seeing the output of ToString() in the debugger, but then several times been bitten by a ToString() implementation that's designed for debugger use and not really for client code to call. A DebuggerDisplay attribute neatly gets round this issue. As you can see, you can execute methods inline in the display, as well as report values of fields and properties. There's a lot more richness to what can be shown in the debugger in Visual Studio 2005 - Morgan Skinner has a great article on MSDN on the topic.

Strongly-typed resource class generator

Visal Studio 2005 has a code generator for creating a wrapper class for your resources. I think you'll agree that
throw new InvalidOperationException(Resources.Extract_HeapEmpty);
is just a bit nicer than
throw new InvalidOperationException(rm.GetString("Extract_HeapEmpty", CultureInfo.InvariantCulture));
Just select the Properties of your .resx file and set Custom Tool to ResXFileCodeGenerator.

You can build a lot of nice code generation technology using the same method this tool uses. Check out the base class on GotDotNet.