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:

• Simplest way to have a configuration file in a Windows Forms C# Application
• 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.

Adim

Your title seems to indicate a bias. You'll get better answers if you make it more of a appsettings vs properties. That's the reason people are getting defensive. Some people nominate to close questions like this - so be careful of them :) – Bojorquez

I don't have a bias. I'm really curious what the advantages are since people seem to use it more often. Thanks for the suggestion though. I will reword. – Adim

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.

Riemann

I'd also second Chris's approach, I've used my own settings class much more effectively than the automatic ones – Gracchus

@Chris Thompson: I agree that there are a number of problems with using the Settings file approach. But, the purpose of this post is to discuss why people recommend manually modifying the app.config INSTEAD of using Settings files. As I mentioned above, I certainly do have beef with Settings files and hence why they would roll their own configuration file. You touched on one of them. – Adim

Good point. Isn't the main problem with app.config is that the application cannot modify the values? E.g., I can't write a GUI to allow a user to customize their settings and save those settings to app.config. I can do that with the Settings approach. – Riemann

@ChrisThompson - Completely agree the issue with Settings file stinks... but still doesn't explain why app.config seems to be more popular. Oh well. – Adim

Answer 2

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.

Koreykorff

Agreed. Someone needs to make a code gen for this though, because hand sculpting them the first couple times is painful. – Bojorquez

Must be missing something here. 1) DISAGREE Settings files also strongly typed 2) Validation can be done with Settings files... I've personally never done it since it's not obvious when using the vs designer support 3) Not really sure about this one... please explain... 4) There aren't any magic strings using the "Settings" approach 5) DISAGREE - The same could be accomplished by using multiple Settings files... each will have their own section 6) AGREE------------- So, i don't agree with your "Advantages" and there are a lot of disadvantages... – Adim

See update for comments. @TheSoftwareJedi--I toy with the idea every so often, but it is pretty hideously complex as the api is so rich. I think custom VS snippets are a good way to handle it myself, but I always forget to write said snippets as one generally writes this stuff once per project. – Koreykorff

I agree that custom configuration sections are often useful. But they do add some complexity: e.g. you need to reference the assembly that defines them in the <configSections> section - with the right version number and publicKeyToken if it's in the GAC. For a few simple settings, appSettings can be simpler. And a simple wrapper class can be used for strong typing. – Prue

I don't see how referencing can be an issue--we aren't talking a wonky third party component but rather a part of the core .NET framework. If the right System.Configuration.dll isn't in the GAC, your app probably is beyond broken. As for the simple argument, it can have a little merit. But it takes maybe 3 minutes to make a simple config section class and wire it up on the other hand. – Koreykorff

"we aren't talking a wonky third party component" - yes we are talking about a 3rd party component (whether wonky or not). YOu need to reference your custom ConfigurationSection: <section name=... type="MyWonkyHandler..." – Prue

Answer 3

Without the discussion, then the answer is:

"Because it's easier."

Blanca

@Doug L. I guess if you weren't using visual studio... I could see that. (Note: I'm not the one who down voted you) – Adim

@Doug I downvoted because I disagree. It's not easier if you're using Visual Studio, and if you aren't then the reason why you wouldn't be is a separate topic (I can't imagine why!!!) – Bojorquez

@Jedi - but you even said below, "...because hand sculpting them the first couple times is painful." Sure, once it's all in place it's great. But in the beginning, app.config is easier and that's why people use it. I didn't say it was best, just easy. It's the path of least resistance and that's the answer to the question. Respectfully... :) – Blanca

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.

Prue

I disagree. I use Settings with apps consisting of relatively independent assemblies each of which requires a few simple configuration settings. It seems easier to have these strongly typed Settings than to have constants for app.config setting names all over your code. – Bojorquez

@Prue In your second scenerio... I think you meant to say "app.config" or "appConfig" and not appSettings. It's really hard to describe these two different methods since they sound so similar. – Adim

@Jedi "...constants for app.config setting names all over your code" - this is a bit of a straw man: the sane way to use appSettings is to have helpers for strong typing and the setting read in a single place (e.g. properties of a static class). But YMMV, I only said they can be simpler to manage. – Prue

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.

Ferrante

Answer 6

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.

Shillelagh

@indyK1ng Both the app.config method and using Settings file both store the default values in the same file which is <exename>.config. So, this issue you present is common to both approaches. The intention of this post was to compare the two approaches. – Adim

Sorry, I'm not that familiar with how Visual Studio does things and thought you were referring to two different files. – Shillelagh

"... Settings file both store the default values in the same file". In a monolithic exe this is true. But for a DLL assembly, the default values are stored in code generated from a configuration file in the assembly's project - these defaults don't have to be present in the configuration file for the exe that hosts the DLL. – Prue

Answer 7

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.

Baerl