Upgrading to Enterprise Library 2.0 (January 2006)

A few days ago I installed the Enterprise Library 2.0 (January 2006) and converted an existing C# ASP.NET 2.0 application (which I had only converted from ASP.NET 1.1 to 2.0 a few days prior) from the Enterprise Library June 2005 bits to the new ones.  The only application blocks that I concerned myself with were the Configuration and Data Access application blocks.

Following are my observations about breaking changes to one of our (Tellus’) ecommerce code bases.  YMMV.

There were very few changes that had to be made to make use of the new code – one is actually mentioned in the Enterprise Library documentation on the intro page for the Data Access Block:

The most significant change is that the Data Access Application Block DBCommandWrapper class has been removed. The new ADO.NET 2.0 DbCommand class provides similar functionality, and the application block was changed to use this new platform class. You will need to modify your applications to accommodate the following changes:

• The Database methods that created and returned a DBCommandWrapper object in the June 2005 release now return a DbCommand object.
• The data access methods of the Database class now accept a DbCommand object instead of a DBCommandWrapper.
• Methods that were available on the DBCommand class but are not available in the new DbCommand class have been moved to the Database class. These methods now take a DbCommand object as a parameter. These methods are SetParameterValue, GetParameterValue, AddParameter, AddInParameter, and AddOutParameter.

Here is an example of code for previous versions of the Data Access Application Block.

C#

Database db = DatabaseFactory.CreateDatabase();
DBCommandWrapper dbCommand = db.GetStoredProcCommandWrapper("GetProductsByCategory");
dbCommand.AddInParameter("CategoryID", DbType.Int32, Category);
DataSet productDataSet = db.ExecuteDataSet(dbCommand);

This code should be modified to look like the following example.

C#

Database db = DatabaseFactory.CreateDatabase();
DbCommand dbCommand = db.GetStoredProcCommand("GetProductsByCategory");
db.AddInParameter(dbCommand, "CategoryID", DbType.Int32, Category);
DataSet productDataSet = db.ExecuteDataSet(dbCommand);

The only other modification that I had to make was to a configuration file that we use. The major change is that there is no longer a  Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationContext class.  This has been “replaced” by an Interface – Microsoft.Practices.EnterpriseLibrary.Common.Configuration.IConfigurationSource.   

Basically all I had to do was to change out references in a couple of places from the ConfigurationContent class to the FileConfigurationSource class, which is in the Microsoft.Practices.EnterpriseLibrary.Common.Configuration namespace and implements the IConfigurationSource interface.  No other changes were necessary and it seemed to work fine.

The other minor difference was that in the past you could just reference the Data Access Block dll or the Configuration Block dll only in your project, now you must also reference the Common dll (or I’ve seen it called Core Class Library in the documentation) for almost any usage of any of the application blocks.  In the case of the Data Access Block (once again taken from the Enterprise Library documentation – intro page of the DAB):

The Data Access Application Block depends on other code included in the Enterprise Library:

• Core library functionality. The Enterprise Library Core provides services, such as instrumentation and configuration, and is a shared dependency of all Enterprise Library application blocks. The core library functionality is contained in the assembly Microsoft.Practices.EnterpriseLibrary.Common.dll.
• The ObjectBuilder subsystem. The ObjectBuilder subsystem performs all the repetitive and necessary tasks for creating and disposing object instances, while still providing a high level of flexibility. Enterprise Library uses the ObjectBuilder subsystem for tasks such as injecting configuration into block classes and connecting instrumentation classes to application blocks. The ObjectBuilder subsystem is contained in the assembly Microsoft.Practices.ObjectBuilder.dll.