Managing App.Config Data

So what is the best way to 'manage' the app.config?

I think that the following conditions are 'desirable' when planning how to manage your app.config.
  1. Like other code, you don't want to have duplicates (including cross project).
  2. You only want data in there that is relevant to the project.
  3. Must be under source control.
  4. You want to be able to define what the variable contents should be in one place only. (where doesn't matter too much as long as it is only one place)
  5. When you make changes to your App.Config, you want to make them whilst you are working on your relevant code change and then forget about it once it has been checked in. By 'forget about it' I mean you don't have to remember to update the file on the UAT box when promoting a new build there and then remember to do the same change to Production...

I should also mention that this is one of a number of articles I'm working on relating to build processes and 'simplifying the boring stuff' so you can focus on what you really enjoy...writing cool code!

Other articles:
http://www.codeproject.com/KB/architecture/CI_Setup_Secrets.aspx
and soon to come will be 'Automating Your Database Updates', but it's taking a bit longer because it comes with some working code which requires explanation...and a bit of cleaning up!

Duplicates

This is particularly relevant for database connectivity data. If you have database connection info in one projects app.config, you don't want to have the same database connection info in another app.config for a different project that needs to connect to the same database.

Relevant Data

If it's not needed it is confusing if it is there.

Source Control

So why mention this, isn't it a no brainer, of course it should be under source control.

The reason why I mention it is this, if it goes into source control, how does the file get updated for the different environments? Do you have one file for each environment under source control? Maybe, but if you do that then if you add some new data you have to add it to all of the files...which is not desirable.

Some of your data will vary for every environment, such as database connection data. Some data will be the same for all environments, such as defining a provider for something and finally some data will be the same for some environments but different in others.

Variable Contents

Some store...somewhere that your automated processes can access easily so they can effectively do a search and replace in the app.config file. There will always be something that is different in different environments.

Checkin and Forget

Once it's done (with unit tests of course) then it is done. Make your change to the file and to the Variable Contents store for each environment (if necessary), then forget about it and get on with coding your next feature. Even when it comes to release the next version no developer should have to remember to make a special change to any file of any type, your processes should ensure the changes that have been made are automatically included. If they don't...change your processes!

What to Do

What I have done in the past (and still currently do on projects like DbUpdater) is store all info for all environments in the one common file (which breaks rule #2). Then there is a post build event which 'pulls' the app.config from common location, putting it into the target directory...looks something like:-

copy ..\..\..\..\Build\Configs\app.config $(TargetDir)\$(TargetFileName).config

My configs are quite simple and it is really only database connection data that is 'muddying the waters'.

What I think should happen (and am planning on doing in the not too distant future) is there should be a command line app that updates the app.config with the appropriate data for the environment. The requirements for the app are:-
  • Command line so my build and release processes can easily run it.
  • Should be able to specify via a parameter what the environment is. (ideally it should be able to work out which environment it is, the parameter simply being an override...that's potential for another article)
  • Should have a store (probably xml which is part of the project) where I can specify all environment specific data.
  • The store should allow me to specify in a fairly easy manner, what needs to be updated (I'm thinking just specify tags to look for and replace the contents within the tags)
  • Should update the contents of the app.config file with relevant data for the environment from my pre-defined store.
  • It should require no human interaction besides updating the contents of the store.
  • It should be simple.

I'm always looking for ways of improving and streamlining the development process so any ideas and suggestions are greatly welcome!

Last edited May 25, 2008 at 3:36 AM by wallism, version 1

Comments

No comments yet.