Why do people consistently recommend using appConf

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.

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.