Best Practices on Configuration Settings

Question

I'm wondering about some best practices out there on storing configuration settings. Let's say you have some settings shared across several applications. I've heard both good and bad ways to store these types of settings that need to be shared (XML files).

Just wondering on what is a good standard in terms of maintaining app settings across builds for easier deployment.

I guess I'm looking at this from 2 scenarios:

1. An application in-house (whether it's a big .com or small admin app).
2. When creating an API for others to consume, how to reference configuration settings when you do not know what the end values will be from the consumer who will be using your API in their application.

---

Added-1:

Thanks. I've heard horror stories where some places have a nighmare managing configuration settings across multiple applications. I am not a build guy so I do not know why but I want to definitely try to make sure I understand it now in terms of web.config vs. custom config files, etc. type of scenarios.

Added-2:

And what about when you are creating an API to be consumed. You have lets say a class that is going to pull certain config information but those endpoints (properties) are not defined until the client consumes your API (specifically C#/.NET)? Where and how would you set those properties in lets say a Configuration Class that you create such as "ApplicationDefinitions"?

Answer 1

If it's across several applications, you can (very carefully) put the settings into machine.config.

Or you can have a separate common config setting repository file that gets read in and used to generate a new web.config every time you build your web application / solution.

Answer 2

What I try to do is separate the config settings that will be different for deployments to different environments into separate files, organized by logical functions, and then NOT include these files in the deployment scripts...

If you're coding in .Net, then settings that are in common across multiple apps can be stored in machine.config... again, don't put them directly in machine.config, but create a reference to a separate file (using a custom defined configSection and configSource="" attribute, to create an indirect reference to that separate file...

Answer 3

Thanks. I've heard horror stories where some places have a nighmare managing configuration settings across multiple applications. I am not a build guy so I do not know why but I want to definitely try to make sure I understand it now in terms of web.config vs. custom config files, etc. type of scenarios.

Answer 4

And what about when you are creating an API to be consumed. You have lets say a class that is going to pull certain config information but those endpoints (properties) are not defined until the client consumes your API (specifically C#/.NET)? Where and how would you set those properties in lets say a Configuration Class that you create such as "ApplicationDefinitions"

Answer 5

We have to support multiple UAT (User Acceptance Tests) , production, development and disaster recovery environments.

Ideally this information would all be in one giant LDAP server..

In the real world we have written an ANT task that uses Jakarta-Velocity as a templating engine. This generates multiple files (UAT, DEV, PROD, DR) from a single template file.

We have a central file that is used for all common stuff and smaller files for individual applications. The command line for any one app need to know whether it is a UAT/DEV.. system etc that is being run, it then loads in the common file and the app specific file.

This works very well in practice and we have been using it for about 8 years. I have seen a lot of other people trying to juggle multiple app files for all their environments and it is NOT pretty. Mistakes are often made.