Most existing .Net code is written on top of the NHibernate or EntityFramework ORMs. In many cases customers do not have source level access to various components that are built on top of these ORMs, or the engineering resources to migrate them to MongoDB, but would like to consolidate DB technologies.

Consider that this would be a strategic advantage for MongoDB, as most .Net CMSes are all build on top of one of the two ORMs.

While Mongo doesn't support joins, most ADO.Net functionality could be implemented, and even pseudo joins on the client could in theory be possible (perhaps enabled with a configuration switch?).

ADO.Net is relatively low level (no high level semantics like joins), so it is possible to implement a provider, and there is copious example code on the Internet for this. The most curious part is the IDbCommand interface and CommandText property, this would require some mapping of SQL to MongoQuery language or Mongo's LINQ implementation; once again there is source code on the Internet for doing this.

Providing this would suddenly open up the entire world of .Net interop and use-scenarios with MongoDB. It would make MongoDB an pseudo-turn-key replacement for MySql, PostGRE, and MsSQL.

Please consider it.

References -

Implementing a .NET Framework Data Provider: http://msdn.microsoft.com/en-us/library/4ksaf9z5%28v=vs.71%29.aspx

ADO.NET: Building a Custom Data Provider for Use with the .NET Data Access Framework: http://msdn.microsoft.com/en-us/magazine/cc301611.aspx

Parsing SQL into LINQ: http://www.codeproject.com/Articles/43678/Dynamically-evaluated-SQL-LINQ-queries