* ADO.NET The coordinator for the ADO.NET implementation is Rodrigo Moya, with the collaboration of: Daniel Morgan, Tim Coleman, Brian Ritchie, and Vladimir Vukicevic. * Action plan

The current plan to implement ADO.NET is as follows:

* Current Status

Variouls ADO.NET Providers have been created: PostgreSQL, MySQL, Sybase, SQL Lite, Microsoft SQL Server, OLE DB, ODBC, and TDS Generic. See their respective web page for more information.

DataSet, DataAdaptor, DataTable, DataRelation, DataRow, DataColumn, DataColumnCollection, DataRowCollection, and others need more work. There are many classes that are just stubs and need to be implemented.

Integration with ASP.NET has not been started, such as, data binding to a System.Web.UI.WebControls.DataGrid. This may involve implementing many classes in System.Web and System.Data. Gonzalo, Gaurav, Leen, Patrik, Duncan, and others are working very hard on the ASP.NET support. If you want to help, contact Gonzalo Paniagua Javier

Integration with Windows.Forms has not been started, such as, data binding to a System.Windows.Forms.DataGrid. This may involve implementing many classes in System.Windows.Forms and System.Data.

Integration with GTK# has not been started, such as, data binding to a GtkTreeView. This may involve creating new classes to go between the glist data model and the ADO.NET data model. Mike Kestner would be the best person to ask for help on GTK#.

Integration with QT# has not been started. Any information on how this can be done is appreciated. Adam Treat would be the best person to ask about QT#.

Integration with GDA# has not been started. It is included in the GTK# project, GDA# does not require GTK+ nor GNOME. GDA# is C# bindings to GDA which is an ADO/OLE-DB like layer for Linux provided as a C library. Classes that would bind data between the ADO.NET data model and the GDA data model will need to be created. Rodrigo Moya is the best person to contact about this.

Integration with GnomeDb# has not been started. It is included in the GTK# project and uses GDA# for its data access model. Creating classes to bind data between the data model in ADO.NET and the data model that exists in GDA# and GnomeDb# will need to be started. GnomeDb# is C# bindings to GnomeDb which uses GDA as its data access layer. GnomeDb is a C API in a library that contains gtk+ widgets (GUI controls) for data access. There are some nifty widgets (GUI controls) that can be used, such as, GnomeDbGrid, GnomeDbBrowswer, GnomeDbSqlEditor, GnomeDbList, GnomeDbLogin, GnomeDbReportEditor, GnomeDbTableEditor, GnomeDbCombo, and GnomeDbForm. Rodrigo Moya is the best person to contact.

XML support in System.Data needs work. This involves working on the classes: DataSet, XmlDataDocument, and the method ExecuteXmlReader() that exists in a provider's class that implements IDbCommand, and others. Stuart Caborn has started the XML support in a DataSet. Tim Coleman started XML support in the ExecuteXmlReader() in a SqlCommand.

ADO.NET Provider Factory has been started by Brian Ritchie. The Provider Factory is used to dynamically create data provider connections and data adapters based on configuration information. This provider factory can also provide utility functions needed by a lot of providers but are not exposed via the provider.

ADO.NET Multiplexor Provider needs to be created. It can use the ADO.NET Provider Factory to create its connections and adapters, but the Multiplexor Provider is a Generic Provider that internally uses an existing provider based on configuration options. This is not part of Microsoft .NET, but it needs to be able to run on Microsoft .NET and Mono. This provider can be a generic provider, much like the ODBC.NET and OLEDB.NET providers are, but be written in 100% C# and be configurable via a configuration file. This provider will multiplex to other providers that exist. If one does not exist for a given DBMS, default to the ODBC or OLEDB .NET provider.

According to Gonzalo, this is how the configuration could be implemented for the Provider Factory and Multiplexor Provider.

After some work done in System.Configuration, you can now do something like: 

 // Get an instance of the multiplexor from machine.config file
 // Can be overriden in the application config file	
 object o = ConnectionSettings.GetConfig 
               ("mono.data/multiplexor");
 if (o == null)
	--- error
    
 Multiplexor mp = (Multiplexor) o;
    
 // may be a string [] argument can help passing arguments
 IDbConnection cnc = mp.CreateConnection (providerName);

and in the machine.config file: 

  <configuration>
   <configSections>
    <section name="mono.data"
      type="Mono.Data.MultiplexorSectionHandler,Mono.Data"/>
    ....
   </configSections>
   ...
   <sectionGroup name="mono.data">
     <multiplexor>
       <add provider="PostgreSQL" 
          type="Mono.Data.PostgreSQLClient,Mono.Data"
          validate="false" 
          parameters="USER=xxx;HOST=127.0.0.1;DBNAME=xxx"/>
     </multiplexor>
   </sectionGroup>
  </configuration>

validate="false" tells MultiplexorSectionHandler not to load the Type until an instance is required. You can add more attributes or whatever inside as long as MultiplexorSectionHandler parses it. 

public class MultiplexorSectionHandler :
IConfigurationSectionHandler
{
    public object Create (object parent, 
      object configContext,
      XmlNode section)
    {
       Multiplexor mp;
       // Here you get the ChildNodes and 
       // set up a Multiplexor
       // instance that will hold the information 
       // needed to create 
       // instances of each provider. Only one 
       // instance will be 
       // created by the config system.
            return mp;
    }
 }

This way, if our providers works with MS, the user can test them in both MS and mono by just adding a few lines to machine.config (i still have to upload a default machine.config file for mono). And this is the .NET way of doing it (of course, if you prefer, you can use the other config file. I just wanted to make people aware of this feature that now works on mono).

Building System.Data

The System.Data.dll gets built with the rest of the class library. To compile the System.Data.dll assembly separately, you need: On Unix

On Windows