The current plan to implement ADO.NET is as follows: +** Bugs and Feature Requests -
SQL# GUI - a GUI tool to execute SQL commands. - Currently, there is SQL# For GTK# which - can be found at - mcs/tools/SqlSharp/gui/gtk-sharp. It has a SQL editor with - syntax hi lighting of SQL keywords - -
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. +** ADO.NET Data Providers -
According to Gonzalo, this is how the configuration could be implemented for - the Provider Factory and Multiplexor Provider. +
Mono has many ADO.NET Data Providers to get you connected: + +
After some work done in System.Configuration, you can now do something - like: +
External Projects that have created ADO.NET Providers that work on Mono: -
-
- // 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> -+** Tools -
validate="false" tells MultiplexorSectionHandler not to load the Type
- until an instance is required. You can add more attributes or whatever
- inside Some tools that can be used for ADO.NET and other technologies (ASP.NET, XML, etc).
- 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:
+ An ADO.NET Provider Factory
+ was created by Brian Ritchie. The
+ Provider Factory is a way to dynamically create
+ connections, commands, parameters, and data adapters based on configuration
+ information.
+
+** Database Access from ASP.NET
-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;
- }
- }
-
-
+
+
+
- On Unix
+** Extra Classes in Mono ADO.NET
+
+
+
+
+
+
- * update your mono sources. Be sure you have latest mcs.exe
- and .dll's, since there have been many fixes needed for
- compilation on Linux.
-
- * compile System.Data.dll:
-
- cd mcs/class/System.Data
+
- mcs --target library -o \
- System.Data.dll @list
-
+
+
+
+
- * update your mono sources. Be sure you have latest mcs.exe
- and .dll's. You can use the same method as Linux,
- or you can use NAnt.
-
- * To use NAnt:
-
-
- cd mcs/class/System.Data
- ../../nant/NAnt.exe
-
+** Testing
+
+
+
+
+
+
-
+
+
+ Name
+ Assembly / Namespace
+ Test
+
+
+
+ Microsoft SQL Server
+ System.Data / System.Data.SqlClient
+ SqlTest.cs at System.Data/Test
+
+
+
+ PostgreSQL (Npgsql)
+ Npgsql / Npgsql
+ *.cs at Npgsql/Test
+
+
+
+ Oracle (Mono)
+ System.Data.OracleClient / System.Data.OracleClient
+ TestOracleClient.cs at System.Data.OracleClient/Test
+
+
- * This will automatically copy the System.Data.dll to Test.
- If you need to do a clean for the System.Data.dll assembly,ODBC (Mono)
+ System.Data.Odbc / System.Data
+ OdbcTest.cs (to connect to MS SQL Server)at System.Data/Test
+
+
- cd mcs/class/System.Data
- ../../nant/NAnt.exe clean
-
-
+
+
+
+
+
+