I know this code has been around for a while, but Craig Andera's 'Last Configuration Handler I'll Ever Need' article is very useful.  He creates a class that implements the IConfigurationSectionHandler interface and uses deserialization to take the config file information and squirt it into a class.  It makes it simple to use a configuration section of a config file as well as making it easy to access these values from a class withoutout having to write any code to hook the class up.  Very nice.

In the September MSDN Magazine Aaron Skonnard provides an excellent explanation of TCP messaging support in WSE 2.0.  He explains the SoapSender/SoapReceiver classes, which provide low-level control over the messaging (you have to manually create a message to send back if you want to support request-response style messaging), as well as the SoapClient/SoapService classes (that provide methods that make it easier to do things like request-response style messaging).

A lot of my Java developer friends give Microsoft a hard time about the design of the .NET Framework Class Library.  Especially with test-first development it would have been easier if the framework used Interfaces rather than classes. 

For example, in ADO.NET it is difficult to write interface-based code because all of the classes are based on the concrete ADO.NET managed provider.  For example, if you want to populate a DataAdapter you have to know what kind of database you are talking to rather than being able to use an abstract DataAdapter and decide at run time what time of database you want to use.  This is because there is no DataAdapter interface, there are only the concrete DataAdapter classes - OdbcDataAdapter, SqlDataAdapter.  Abstract ADO.NET is an open source project that provides a set of interfaces that overcome this problem (as well as the issue of creating connections and handling exceptions).  More recently Microsoft have updated their Data Access patterns block with an Abstract Factory pattern, making it easier to write NUnit tests against different database providers (as Steve Maine notes)

Jon Lam has a good posting that Unit Tests of the UI are difficult because of the lack of interfaces.  In the comments, Joe Beda from Microsoft offers reasons why Microsoft prefers classes over interfaces:

Generally, classes are preferred over interfaces for a variety of reasons. I'm not the expert here, but versioning is definitely the big reason. Since you can have "default" implementations to go along with a virtual on a base class, you can add new functions in v.Next and provide a default implementation. With an interface, once you ship that interface you are stuck with it forever. You can't add new methods to that interface.

Also, any time that you pass that interface to the "system" there is an implied contract about how and when the system calls you back on that interface.