Supporting multiple configuration environments using the EntLib config tool

One of the more frequent questions I have heard about Enterprise Library is how to efficiently manage configuration information across multiple environments (eg DEV, TEST, PROD etc). The problem is that most configuration settings are shared across all environments, but certain key settings, such as server names or connection strings, can be different. The standard solutions are to either maintain completely separate configuration file sets for each environment (which can lead to inconsistencies where a change isn’t made consistently across all environment files), or to keep a single configuration file set and make the necessary changes for each environment when an application is deployed (which is inefficient and error-prone).

We are planning to have a better solution to this problem in Enterprise Library for .NET 2.0. But in the meantime, Olaf Conijn has put together a simple and elegant solution that solves this problem today with Enterprise Library June 2005. His solution is a new application block which can extend the configuration of any existing blocks by letting you specify environment-specific overrides on a per-node basis. It then saves a complete set of application configuration files while maintaining a single source across all environments. The coolest thing is, he achieved this without needing to change any existing Enterprise Library code! (Also check out this other post about some scenarios where this can be used).

If you have had challenges maintaining configuration across environments, I strongly recommend you take a look at this. And we’ll definitely be talking more to Olaf as we continue development on the next version. Thanks Olaf!

Comments (1)
  1. Brad Hehe says:

    After looking at how the solution was created by Olaf, I would like to point out 1 scenario that I’m unsure the solution would work.

    Let’s say you’re developing a tool to migrate data from one instance to another DEV->QA->PROD or similar.

    With that scenario, for a given "object" I might need to perform data access against *both* environments. So an "environmental override" wouldn’t exactly work.

    Hopefully the future configuration and data-acess blocks will be able to accomodate a scenario such as that since I wouldn’t think it’s uncommon.

Comments are closed.