About Links Archives Search Feed Albums of Note

ASP.NET 4.0, Part 4: Config Transformation Files

Welcome to part 4 of my tour through ASP.NET 4.0 [http://blog.hmobius.com/post/2010/02/09/ASPNET-40-Cometh.aspx]. In this instalment, we’ll be looking at a new feature in VS2010 – configuration transformation files. We’ll see the scenario that it addresses, how you’d deal with it in VS2008, how it compares to this part of the new Deployment process in VS2010, and what your options are.

One Configuration File, Many Web Servers As web developers, we all know that a single web site may well end up deployed on several sets of servers during its development and maintenance lifecycle. At the very least, it will end up on two – your development machine and the live server. (I mean you don’t run your live websites on your dev machine, do you?) In most cases, there will also be a staging server where clients can access sites in development for testing and feedback as well. And with different servers come different database connection strings, different mail server settings, and in fact many other settings stored in your web.config file that you need to change per server.

The Manual Approach You might try and make these changes manually each time you deploy a new version of the site to a server, perhaps for example having all the correct database connection strings in the web.config file and commenting out all but the correct one for the target servers, once deployed.

This is fine for very simple config files with only or two lines of config to change, but when you’ve even just five separate sections to change per deployment, it gets very tedious and prone to error very quickly. Which is where Web Deployment Projects [http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx] take over.

Using Web Deployment Projects An out-of-band release for VS2008 that appeared for download in January 2008, a Web Deployment Project (WDP) provides a configurable post-build step in VS2010 for web developers. Or, in English, adding a WDP to your web project means that you can specify a number of other actions for VS2008 to perform on your code once it has been built, as well as whether it should pre-compiled or not. Crucially to this discussion, this dialog allowed you to tell VS2008 to replace sections in your web.config file with the contents of another file.

So then, your base web.config would contain the settings for your development environment. Or, if you prefer, links to files where the settings that would change between servers are located. For example,

<system.net> </system.net>

And, as VS2008 goes through its post-build step for a Release build, it changes the references from these development environment files to their live equivalents, as specified in the screenshot above.

<system.net> </system.net>

If you’re feeling adventurous, you could even get VS to delete the development environment files after a release build as well. You just made a few additions to the MSBuild file for the WDP itself, as follows.

On the whole, this is manageable, assuming you don’t mind the large number of config files you potentially end up with.

If you’re curious to read about all the actions possible with WDPs, please check out Scott Guthrie’s post here [http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx]. It is targeted at the VS2005 version of WDP but the 2008 version differs only slightly.

Enter MSDeploy and Config Transformation Files Config transform files (CTFs) are part of the new deployment process and in isolation are set up in a very similar fashion to how WDPs work as detailed above. When you add a web.config file to a web site or web application project, you’ll also see a number of CTFs added too, one for each build configuration you’ve created. If you create any further build configurations after you’ve added web.config to the project, simply right click on web.config in Solution Explorer and select Add Config Transforms. Additional CTFs will be added for each new build configuration.

The basic strategy for these files is to create a base level of settings in web.config – essentially, what’s needed to get things working in your development environment – and then use the CTF for a specific build configuration to tell VS how to change web.config for that build. Look in Web.Debug.config and you’ll see that no changes will be made. Look in Web.Release.config and you’ll see the following (minus the comments)

<system.web> </system.web>

An educated guess will correctly tell you that this is an instruction to remove the debug attribute from the element whatever its value, thus setting it to the machine-wide default of false.

CTFs share the same schema as standard .NET config files but declare a second namespace which gives you two extra attributes to set down on any element in the file : Locator and Transform.

Locator Locator identifies the element or attribute to be altered in one of four ways. Its syntax is

Locator = “Command()”

where Command is one of three possibilities

The fourth way to use Locator is to omit it. If a Transform attribute is set on an element without a Locator, it is applied to that element, as demonstrated in the example straight from Web.Release.config above.

Let’s demonstrate the first three options by using each in turn to do the same task: change some mail settings. In our standard web.config file for development purposes, we use pickupDirectory to test email.

… <system.net> </system.net>

but when deploying live, we want to use an actual mail server and have the mailSettings look like this

… <system.net> </system.net>

We can achieve this transformation by using Condition to affect all smtp elements with deliverymethod set to SpecifiedPickupDirectory, like so:

<system.net> </system.net>

Using Match rather than Condition, we identify all smtp elements that have a from attribute with value to transform. They key here is that the attribute being matched will not have its value changed.

<system.net> </system.net>

Finally, you can use XPath to specify absolutely the element or group of elements to transform

<system.net> </system.net>

This simple example perhaps belies the potential on offer here. Because we are using XPath expressions, we can potentially affect groups of elements in web.config rather than just the one, or elements if only certain conditions are met. But aside from a direct replacement as demonstrated above, what other changes can we make?

Transform The Transform attribute defines exactly what alteration to make to an element. Its syntax is


where command is one of xyz possibilities. (Code samples here are snippets rather than full CTF listings.)

<system.net> </system.net>

Phew! I hope you can see how powerful CTFs can be, especially if you use the power of XPath to identify elements to transform. If you’re new to XPath, the w3schools introduction to XPath is a good place to start [http://www.w3schools.com/xpath/default.asp].  You can find more information and examples on CTF syntax here [http://go.microsoft.com/fwlink/?LinkId=125889]. Until the next time, happy coding!

Posted on February 17, 2010   #ASP.NET     #Geek Stuff  

← Next post    ·    Previous post →