Thirteen Days a Week

My current project is a rewrite of a legacy system.  The client wants to be able to start leveraging the new system as we complete certain features, so this means that we need to integrate with the legacy data store.  In this case, the legacy data store is a Pervasive SQL database.  Prior to this project, my knowledge of Pervasive was limited to the fact that it was a btrieve database.  Needless to say, it’s been quite a learning experience working with Pervasive.

I was pleasantly surprised to find that Pervasive does in fact provide an ADO.Net provider.  I also found some info on Pervasive’s website that indicated they’re working an an Entity Framework provider for their next version.  We had decided to rely on Enterprise Library for our data access strategy, though Pervasive doesn’t provide an Enterprise Library provider.  EntLib does have a GenericDatabase provider, however this is limited in it’s features, specifically around the handling of parameters.  So, with that in mind, I decided to undertake writing a custom EntLib database provider for Pervasive.  As it turns out, it’s really not that daunting of a task.

You’ll need two classes, one to represent the database and one to handle registrations of the provider with EntLib.  The database class derives from Microsoft.Practices.EnterpriseLibrary.Data.Database and the registration class derives from Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseData.  Class diagrams of my Pervasive provider are below:

The bulk of the code in my PsqlDatabase class is related to handling of parameters and the parameter token used by Pervasive.  For the record, Pervasive’s parameter token is a colon.

Once you write your code, the last remaining task is to wire it up to EntLib via your configuration file.  My configuration is shown below:

At the top of the config file, we have the usual configSections entry for using the EntLib data access block, followed by the dataConfiguration element.  This is where the magic happens.  the providerMappings element is used to map our custom database type to the registered ADO.Net provider.  Then, since Pervasive doesn’t register itself in machine.config, I have to add the Pervasive factory class in the system.data/DbProviderFactories section.

That’s all there is to it.  While my example is specific to Pervasive, it could easily be adapted to any other DBMS that has an ADO.Net provider.  If you decide to undertake creating your own provider, I would recommend reviewing the EntLib source control, specifically the classes that support EntLib’s SQL Server provider, those were really helpful to me when I was getting started.

Recently I started on a new project, with a new client.  As the project is new and the client doesn’t have an established .Net development group, we’re finding out that some things which we would often take for granted just aren’t in place.  One thing that came to light early on was the lack of a repeatable deployment process.  We’re scheduled to have a dedicated build and deploy person on our team in a few weeks, but in the meantime, I find myself in the undesirable position of having to manually deploy and configure our solution to our dev and QA environments.  Our solution consists of an ASP.Net MVC application and three WCF services.  Each of these pieces of the solution has some degree of configuration data that needs to change with each environment.  These changes include things like connection strings (database server name), WCF security settings, etc.  Without any kind of automated deployment process in place, that means I need to manually edit our configuration files each time we deploy.  Personally, anytime I need to manually edit configuration files, I manage to screw them up in some way.

So, with the prospect of another month of botched deployments in mind, I decided to see if I could find an easy solution to getting builds setup for our dev and QA environments.  One of the things I noticed early on with Visual Studio 2010 ASP.Net projects was that for some reason, I had a couple of extra configuration files:

Since part of the problem I was trying to solve related to configuration data, I decided to do some research to find out what these extra config files were and if they could help me.  I came across this blog post which provided me with the info I needed.  As it turns out, the additional files, Web.Debug.config and Web.Release.config are referred to as config transforms.  The idea is that you use web.config as your baseline, with the settings you need for your local development environment.  Then, for each solution configuration, you have a configuration trasnform file which has the changes you want to apply to your baseline configuration for that particular environment.  When you create a new solution, you have initially Debug and Release solution configurations, so that’s why you see Web.Debug.config and Web.Release.config.

In our project, since we currently have only dev and QA environments, I went ahead and added two new solution configurations, called dev and QA.  After adding the new configurations, to add the web.config transforms, you need to right click on web.config and select Add Config Transforms:

Your project should now look something like this:

Once you get your config transforms added to the project, you need to edit your transforms so that they contain the changes you’d like applied to your baseline.  There’s plenty of good info on MSDN and elsewhere online on how to do this, so I’m not going to go into this much beyond a quick example of what a simple transform might look like:

The top file, web.config is my baseline and has a connection string that’s pointed to the local default SQL server instance.  Below, we see the transform for the dev environment.  Notice the connection string has a different SQL server name and has a couple of extra attributes.  xdt:Transform and xdt:Locator control how the config transform build task applies the changes to the baseline.  In this case, I’m saying that in the baseline config, replace the connectionStrings/add element that has a name attribute matching AppDataDb.

Now that we’ve built out all of the config transformations, how do we incorporate them into a build?  Visual Studio 2010 provides packaging functionality for web applications which apparently takes advantage of the config transform feature.  However for reasons I won’t go into here, I’m not able to use packages for deploying in my current project.  Instead, modified our project files to have an AfterBuild task that runs when our apps our built on our build server.  This task takes care of applying the config transforms.  To make the this process easier, I installed the PowerCommands for Visual Studio 2010 extension, since this has an option to directly edit project files.  After you install the PowerCommands and restart Visual Studio, right click on your project file and select Edit Project File:

Scroll down to the bottom of your project file and find the AfterBuild event.  Depending on what kind of web project you’re working with, this may be commented out, if so, uncomment it.  We need to add a TransformXml task to the AfterBuild event, like so:

Note that in my case, I was working with an ASP.Net MVC project which already has a task in the AfterBuild target, the AspNetCompiler task.  In an MVC project, the AfterBuild target contains the condition “’$(MvcBuildViews)’==’true’”.  This is to enable view compilation, which is disabled by default.  You can either set the MvcBuildViews variable to true in your project file, or, as I ended up doing, move the condition from the AfterBuild target to the AspNetCompiler task.

So, with our config transforms completed and project edited, all that remains is to setup TFS build.  All I did here was to setup new builds, one for each of our configurations, setting each build to use the appropriate solution configuration (dev or QA).  I’m far from a TFS expert, so I’m sure there are better ways to handle this, but for our simple needs, this seems to be working just fine.