Why use app.config to store config data?

Question

I am currently completing an application that was started by someone else. He is using the app.config for some settings, and a custom xml file for other parts. This drives me nuts, and I want to consolidate the configuration into one file.

But I am not certain wether to move everything into the app.config and throw out the custom xml file, or move everything into the other file and forget about app.config.

I can see two arguments, one for each option:

1. Using the standard way provided by Visual Studio is easier to maintain for somebody else than me.
2. I can validate the custom file against my own xml schema, thus outsourcing a lot of tests if the config file has all required data etc.

But I'm certain that there are a lot more things than I can think of right now. That's why I'm asking:

What are the advantages or disadvantages of using app.config for storing your configuration versus the 'traditional' configuration file?

Answer 1

The main benefit of using the app.config is that it is the default, supported way for a .NET app to store its config. Anyone using that app or inheriting it from you some day will thank you for using established standards instead of "rolling your own".

Also, the .NET framework has support for using, writing, creating, modifying the app.config file - if you go with your own scheme, you'll have to re-invent the wheel many times over.

So I would definitely recommend using app.config - it's THE way to do configuration in .NET and a widely accepted and well-supported standard.

Marc

Answer 2

Simplicity and program readability.

App.config is a normal method in .NET for storing configurations, so its likely other programmers will have seen it. It's stored in XML, so there won't be any performance vs. an XML configuration file.

It also handles location of where to save the app.config (Documents and Settings/username/Local Settings/Application Data/your app/) and saves configurations automatically based on the location and version of your application, to allow multiple versions of the same application to co-exist.

I'd say there isn't a need for BOTH app.config and a custom XML file, so combining the two may be a good idea.

Answer 3

IMHO app.config is not a very convenient way of storing config data, mostly for those two reasons :

• You have no control over the location of the file
• You can't define your own structure to organize configuration settings

I prefer to use my own configuration class, which I load and save using XML serialization. You still get the benefits of strong typed settings, and it's much more flexible since you can define any structure you want

Answer 4

Splitting the configuration into different files is very useful if the lifecycle of your project has it moving from one environment to another.

For example, when the developers are working on the code, you may want the app to point to the 'devsql' box. When it's time to be QA'd, the code gets deployed to a staging server, and you want the app to point to 'stagingsql'.

If you keep all the configs in app.config, and a settings change has been made to the dev version of app.config, it will get copied up, and clobber the staging version - now your QA people are pointing to the dev database.

By keeping 'database.xml' seperate from 'app.config', you can allow for differences between the various environments, but still allow changes to config files to flow from each environment to the next without worrying about overwriting a customization.

Answer 5

I agree that the XML serializer combined with a "Settings" class is an excellent place to store your settings, especially if you have a lot of custom types or objects.

Answer 6

It's very easy to create classes to define your own configuration sections in Web.config, which will give you strongly typed access to your configuration data, allow you to define a sort of schema for the configuration information, etc. See, for instance, this article [4guysfromrolla.com] for implementation details.

Answer 7

App.config have good support to connection and logging configurations, which you will use in almost all applications. Rewriting them may bring you a lot of work. Also, you can have some structure flexibility if you use "sectionGroup" on your app.config.

But before doing something, I would ask to the guy who created the custom configuration file why did he do that. There are some unusual situations in which app.config brings you some trouble, like if you want to load another DLL(with its own app.config) by Assembly.Load. In this case you will need to consolidate the two configurations in one single app.config, and pray that they won't have any configuration with the same key.

In webtests, you can't overwrite web.config configurations, so it can bring some trouble too, deppending on what you want to do.

But IMHO, it's only in unusual situations that app.config won't make its work well. In most common cases, i think it's not worth creating your own configuration framework.

Answer 8

App.config is the default and for most cases is the best way to handle application Configurations, having said that there is a cost to it when you need to parse the file to get values out and when the file gets big enough this becomes a problem.

This is more of an issue with web apps that have large web.config files, every time you make a request the web.config get's parsed and this can get taxing, you'll see this with some ORM mapers.