Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
Related : stackoverflow.com/questions/4960519/… –  rlb.usa Jun 2 '11 at 18:18

4 Answers 4

up vote 0 down vote accepted
+50

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.

share|improve this answer

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

share|improve this answer
    
If man cannot walk you give him a wheelchair not move the world around him... Sorry but i think its horrible decision, I may be wrong but thats my opinion. –  JackLeo May 31 '11 at 5:54
2  
So do most other people that start here until they watch us roll out the software and every thing just works with no need to change configs for test and live. –  Erin May 31 '11 at 13:36
1  
We work the same way. I understand it can't be done in some places, but if you can it makes things much simpler. –  DaveE May 31 '11 at 18:17

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.