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

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

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 3

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 4

I also would like to point out one difference between app.Config and Settings window. If you save anything under Settings then the settings will be saved on following locations.

Win XP: c:\Documents and Settings\%Username%\Local Settings\Application Data{Publisher Name}\

Win 7: C:\Users\%Username%\AppData\Local{Publisher Name}\

While the app.config settings are saved on in the config file only.

Answer 5

Because the Settings file infrastructure is (1) more complex and (2) insufficiently documented given its complexity.

The way Settings files work by default are useful for small applications. For bigger ones you often need to change this default. The Settings file infrastructure could be leveraged to your needs, but there is a steep learning curve involved, even with good documentation. Without documentation, it's near to useless.

I just refer to this article to conclude. Feel free to paste some useful links to conceptual MSDN documentation to contradict my argument.

---

Update:

I need to be fair and supply a specific use case which I didn't find documented:

I like the application settings designer. I also like the XML format of the stored settings. I wanted to retain these features, but use other locations where to store the settings. I didn't find any hint whether this use case was supported, and if yes, how to accomplish the task.

Answer 6

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.