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:
From my viewpoint there are following advantages of the "Settings file" approach:
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.
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.