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 web.config) like so:

<configuration> 
  <appSettings>
    **<add key="ConfigValueName" value="ABC"/>**
  </appSettings>
</configuration>

Then, accessing them like:

string configValue = Configuration.AppSettings["ConfigValueName"];

I'll refer to the approach outlined above as the "app.config" approach. Very rarely do I see people recommend adding a "Settings" file to the project. I've seen this so many times across the web and on stackoverflow... I'm starting to wonder if i'm missing something... because I'm not sure why you'd use this method over using a "Settings" file. I didn't get into .NET until VS2005 so one theory I have is this was how things were done in VS2003 and people never switched over?

Examples of people recommending the app.config approach:

• http://stackoverflow.com/questions/114527/simplest-way-to-have-a-configuration-file-in-a-windows-forms-c-application
• http://stackoverflow.com/questions/535685/best-practices-how-should-i-store-settings-in-c-format-type

From my viewpoint there are following advantages of the "Settings file" approach:

1. Can be used for both Application Settings (those that are common to all users) and User settings from the same interface.
2. Ability to use the Settings designer support in visual studio. Less error prone then editing an XML file directly IMHO.
3. Refactoring - you can rename a particular setting name and it will automatically update references in your code.
4. Compile type checking.
5. Auto-completion support.
6. Property-Grid Capabilities. I have found that the PropertyGrid control is a very easy way to make a quick options form. You just do propertyGrid1.SelectedObject = Settings1.Default; and you're done.

In case you are not sure what I mean by the "Settings" file approach see this post which is one of the few examples where someone recommends using Settings files instead of app.confg.

EDIT: Please understand: The intention of this topic is to figure out why people would use the app.config approach outlined above over the Settings file approach. I have encountered the limitations of the Settings file approach and have been forced to roll my own custom solution at times. That's an entirely different discussion.

Answer 1

I believe that the biggest difference between the two is that the application cannot change the values in app.config. Those values are read at runtime and there's no built-in support for writing new values to the configuration file.

Settings files can be changed using the Save() command.

One major problem with the built-in support for Settings files is where the settings file is stored. If you look at your APPDATA folder, you'll see that there is a folder for the name of the company, then a sub-folder with the name of the product, then a sub-folder with a semi-random name and version info.

Whenever you release a new version, it won't locate the Setting file from the previous version because of where the Setting file is stored. There's also no way to change where the Setting file is stored.

I used it in one project and found it much more useful to create my own AppSettings class that uses an XML file for settings. I have control over the format and location of the file.

Answer 2

Incorrect: Part of the problem with the settings file approach is that it requires the app to be in a specific place and the settings file to be in the correct place. If one of these gets accidentally moved, then the settings can be lost for good, same as if it gets deleted. There could also be the issue of multiple settings files with the same name in the folder, causing one to be overwritten. This is particularly bad if the software is dependent on the settings file. These problems aren't nearly as pronounced with installed software, but in software which isn't installed, but simply downloaded and run it can be a major issue. Imagine if someone downloaded several of these programs to the same directory and they all used the same settings file name.

EDIT: As discussed with the person who asked the question, this answer is incorrect because the question is referring to two different ways of saving to a settings file. When I gave my answer, I was thinking that he was referring to two different files. About the only other answer I can provide is that it's a matter of personal preference.

Answer 3

Without the discussion, then the answer is:

"Because it's easier."

Answer 4

Two scenarios:

• A client app which is shipped with configuration settings set to default values. The app provides a UI to modify the settings for a single user or all users.

Here the "settings" approach wins hands down.

• An app consisting of several relatively independent assemblies each of which requires a few simple configuration settings. The settings are normally set by an administrator and are not modified by the application once deployed.

Here "appSettings" can be much simpler to manage. With the "settings" approach, there will be a section for every configurable assembly to be added to the main application's configuration file.

Answer 5

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 <add name="foo" value="bar" /> 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.