My #1 grip with the Framework deals with ADO.net and the way they chose to implement the provider-specific mappings to native framework types.  The "generic" way to access a db is almost completely useless unless you are married to Sql Server.

There is no base type to deal with high-precision numbers that come out of a database.  Even with Sql Server you're forced to use the provider-specific types like SqlNumber and OracleDecimal, which are not related (which is impossible with ValueType I know) and provide horrible conversion implementations to the native types.

Of course the root problem is the lack of a true standard for dbs to represent data, and dbs like Oracle that have zero compatibility with accepted number standard like IEEE, but that's another story.  If System.Decimal better represented the numbers a db is capable of storing that would be a huge help.  Or even adding something like BigDecimal to handle high precision cases would be nice.

In my opinion, ADO.net has not succeeded in providing a cross-db interface to data.  Instead of providing the Bridge pattern to many different database API's, the managed providers are forced to implement features missing from the bridge, thus eliminating its advantages.  Some people may never run into these problems, but working with Oracle at work (which I've grown to hate) keeps me from using the managed providers without creating my own wrappers for the "special cases" that happen every time I query.