Let’s start out with a little history here.

About 1.5 year ago I worked as a development coach to a team of programmers at a large dutch insurance broker. To satisfy some of the infrastructural requirements we spec-ed in enterprise library v1. The team I worked at had a pretty sophisticated build environment set up and all sorts of procedures and protocols to propagate changes to different environments (test, production and so on). Since the project just started we were still trying to make sense of all of these processes and figuring out how we could comply with these, at best. As with most problems, the fundamentally better you would like to solve them, the more complicated they become. This at least was the case for managing and propagating changes to the configuration files within these environments. I had a fair understanding of how Enterprise Libraries configuration tool worked and how to extend it and during a month-or-so holiday at my family’s vacation house in Finland I hacked something together that would solve this particular problem. For kicks and because I felt this particular problem had bugged me for long enough.

Quickly after posting this solution on my weblog, the patterns & practices team contacted me and engaged me on a contract to work on Enterprise Library v2. Unfortunately the feature got cut and most of my time was spend on more sensible Enterprise Library v2 features. This time around (with Enterprise Library v3 on its way) the extension finally made it “above the line”.

So, what is this “environmental overrides”-thing and what value does it add to Enterprise Library?

Environmental Overrides is an extension to Enterprise Libraries configuration tooling that can help you keep track of differences in configuration throughout your infrastructure. The extension is part of the designtime and not of the runtime parts of Enterprise Library, which means that it will be compatible with any application written on top of Enterprise Library.

Managing differences between configuration files can be done in the same view you would edit configuration settings for a particular “Configuration Node”. For each environment configured in the editor you will have the possibility to either “override” the settings for a particular environment, or keep the settings for this environment in sync with the original. Configuring the environment can be done from within the configuration-treeview, adding new environment nodes underneath the “Environments” node.

A configuration hierarchy that contains 2 environments ‘Test’ and ‘Production’ of which one has different values the LogEnabled filter.

Every environment that is configured in the tool, will maintain its own “Environment Delta File” (or .dconfig file), which is updated after saving the configuration as a whole. This Environment Delta File contains all the differences specific to that environment and some additional metadata for merging the differences into a new and complete configuration file that can be deployed. The main advantage here is that an Environment Delta File can be distributed separately of the original configuration file and managed by someone that has access to all the passwords, server-names and whatnot of the different environment.

Relationships between Original Configuration File, Environment Delta File and Merged Configuration File.

Another new and hopefully useful addition is the ability to merge the Environmental Delta File and Original using a command line tool, which allows automating this process within for instance a build or integration server.

The Environmental Overrides extension will be included in the next CTP of Enterprise Library 3.0, available soon –in a web browser near you! www.codeplex.com/entlib