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.