Why do people consistently recommend using appConfig instead of using Settings files? (.NET)

Question

Very often I see the answer to the question like: \"How should I store settings in my .NET app?\" is to edit the app.config file by manually adding entries to the app.config (or

Answer 1

There is a third, and much, much better way than either AppSettings or Properties: custom configuration sections. Advantages over AppSettings:

1) Strongly typed access

2) Built-in validation mechanisms for both the schema and the form.

3) POCO based making it highly testable--just new up your own test config.

4) No reliance on magic strings. Not that you can't easily wrap AppSettings in a class and access it that way, but 95% of developers don't.

5) XML in the configuration becomes much more intelligible once you get to a dozen or so settings. Also much more intelligible than the Propterties bits IMHO.

6) No reliance on visual studio to make it work well.

Granted, I never really used properties because I got my hands on custom configuration sections first.

BTW, if you haven't heard of these, you are still using them every day--what do you think the standard config sections in the .NET configuration files are?

_____CLAIRIFICATION SECTION

First, the bulk of this was aimed towards the AppConfig approach, and re-reading I wasn't clear. I think we're generally on the same side--avoid the loose name-value bag for configuration because it breaks too easily. I should also add that I am a web guy, so user settings are something that lives in the application layer, not in config, to me.

1) True, both Properties and custom config sections have strongly typed access. AppSettings don't. AppSettings bad, Props/CC good.

2) When you load a configuration section, the application will throw a configuration exception if it does not expose necessary information or improper information. Same as when you muck up a app.config or web.config. There is a bit more validation infrastructure I haven't used because I like to fail hard and early or not at all.

3) POCO is plain old C# object in case anyone missed the last few years. Anyhow, because config settings are decorative and declared via attributes, your config settings can be easily tested because you just need to delcate a new MyConfigSection() and set properties, etc, as appropriate. As I understand properties, you need to have the configuration file there with the right xml in it or you are sol. Other advantage is custom config sections work with all the other neat stuff you can do with POCOs, like interfaces and dependency injection.

4) True, both Properties and custom config sections are strongly typed, AppSettings are not. AppSettings bad, Props/CC good.

5) Really aimed at the AppSettings. I've inherited a few apps with litterally 2 pages of in the config. That is easy compared to the xml jibberish that properties spit out. On the other hand, your custom config section can be rather semantic and self-explanitory because you are declaring the section names and attributes. I can pretty easily edit it in notepad on the production server and not be too nervous about shooting myself in the foot in a pinch.

So, outside of not having a VS-based property grid (which I would contend is a bad thing--why do you need a grid to edit configuration?), custom config sections have alot of advantages and no real disadvantages compared to Properties. Both custom config sections and properties have massive advantages over AppSettings.