Managing large number of app.config files

Question

We have many windows services and web apps which all rely on a lot of common settings. Currently we use just appSettings as needed and they are referenced by key. Some of the settings are app specific and only know by the app team while others are environment specific and only know by the deployment team. Also we have issues when we have to make a change to common setting necessitating the change 100s of files and restarting all corresponding services. With the great variety of settings there are duplicates ones that are no longer used and many that don't mean the same thing to different applications.

To solve the problem I had a two fold idea one we would write a custom config sections group for the company with custom config sections for each app and one for common. The common section would be able to accessed by a wcf service and validate that all of its settings are the current settings.

My question is am I reinventing the wheel are there any good frameworks/projects/products that are designed to manage many many configurations files in a distributed environment, and if not is the approach I have decided take a reasonable one.

Answer 1

I suggest to use some sort of wiki or documentation engine in your workplace.

Sure you can upload quite similar files to server, but thats the place where sometimes we forget to look at. Just think how many times you downloaded an app for development purposes and started reading README.txt, or just jumped to that app webpage and started reading documentation. Sure it may just be me with Linux fashion but still...

Sure this will only eliminate problem that your coworkers don't know what and how you're working.

For managing settings - just split those. If some settings are needed specially for the app why the app has no config file of its own? Common settings should just respond to environment in my opinion while custom app settings should have settings for its [apps] own purposes, don't be scared for settings multiplication, because you will be able to manage those settings without fear that you'll crash some other app. If you think managing such amount of settings is harder - remember thats it's common practice to use one file per model. Why not do the same with settings? Also there is Name_spacing option but in that case your config file will be HUGE, therefore i suggest you to use spited settings just like @Travis suggested.

Answer 2

We had a similar problem at my work. We solved it by not using the config files. We wrote the things that when changed required a code change any way in code, and then moved the rest of the properties to a settings table in a database. We wore able to do this because we control every server we deploy code on. This change simplified our systems drastically

Answer 3

For current applications, if it is not broken don't fix it - You may create a huge mess if you start playing with settings needlessly in several applications. For new applications, simply, put your shared settings in a database.

Answer 4

You can include an external file in your app.config for only appSettings. The included file is pretty limited in what you can have in it (only appSettings node) but it is helpful if you want to just shared stuff.

\Software\Services
    shared.config
    \Service1
        service1.exe
        service1.exe.config
    \Service2
        service2.exe
        service2.exe.config

In this case you just have service1 and service2 reference the shared.config.

Additionally, having a configuration service is also something I've done, esp. when there are a large number of applications. Services are a bit easier because they often reside on the same box. When you have many web apps on different boxes then you need something else external to reference.

Edit, I should have included a link to an example http://weblogs.asp.net/pwilson/archive/2003/04/09/5261.aspx.