When to use .NET Settings vs config <appsettings>?_问答_开发者

Are there any recommendations on when to use Application settings (not per user settings) vs. .config file <appsettings>?

Update

Looking to 开发者_如何学编程understand some of the finer and important differences because they're both effectively key/value stores. For example, I know modifying appsettings in web.config will recycle the web application.

Settings have been in .NET for a while now and I haven't bothered to look at them - maybe one is somewhat redundant, or using both at the same time doesn't make sense... that's the kind of detail I'm looking to understand and the reasons.

The question is a bit old but I stumbled upon it and thought to add some clarity in case someone else also stumbles upon it...

The settings option (as opposed to the raw <appSettings> section) has strong support in the framework:

Settings are strongly typed (i.e. bool, int, ConnectionString, etc) instead of all being returned as string to be parsed by your code if needs be.
Settings can be scoped to be a) Internal or Public, and b) Per User or Per Application (the latter essentially meaning Per Machine).
Your application would need to supply its own interface for changing the settings, but that's fairly trivial as the setting properties are read/write in code, and the generated class supplies functionality for saving the changes.
The app.config (or web.config) file that is deployed, only stores the default values (see below for how runtime changes are handled) - which means that changing settings and saving them at runtime doesn't change the .config file - and by extension doesn't cause a restart of your application.
Changes at runtime are saved to a local location (somewhere in either c:\ProgramData.. or c:\Users\MyUser\AppData\Local..) depending on the scope chosen. As such, subsequent releases of your application can safely introduce new settings without fear of trashing previously customized values, as they are safely stored away.

Hope that helps to clear things up a bit.

One point that seems to be overlooked from the answers so far is that .config files can be transformed using Transformation files. These are available for Web.config files by default (in Visual Studio) and are enabled for arbitrary .config files with the SlowCheetah - XML Transforms add-in for Visual Studio (SlowCheetah also adds a previewer and applies transformations on build rather than just on deploy.

Application settings and config file appSettings sections are limited to key value pairs, which are good for simple settings, but if you need a data persistence that is more robust you might look at creating a custom configuration section for your application. Here is stackoverflow article on creating a custom config section

Enjoy!

Application settings can be typed, which is a plus compared to appsettings. And the way you can access them is a little more neat (property) then getting a value from an array.

And you can use the interface to implement a settings class that stores you settings in a database.

One thing to be aware of is, if you're deploying via ClickOnce despite the fact that config files are now writable they are not in a ClickOnce deployed app since that'll stuff with it's file hashes.

Therefore, the rule of thumb is that anything that's environment configuration goes in app.config. Anything that's user configuration goes in Settings.

Sometimes the line is a little fuzzy so for those fuzzy ones I would wrap in a static accessor method so that you can move them around at will.

Something I've done before is to create a class that contains properties appropriate to the settings to be persisted. A class instance is then XML serialized to a file, and can later be deserialized to get back the same object, property values intact. And the application will not need to be recycled, which it would if you write to the web.config/app.config file.

You can get strongly-typed application settings this way, and don't have to worry about keys and values. This has worked fairly well for me when I wanted to provide user-settable options within the application.

Application Settings do not get compiled into the assembly.

I'm not sure but I think that the Application Settings default values are compiled into the assembly, but these can be overridden in the config file.

I think Application Settings was created as a more friendly way of doing it, especially from VB.Net, but I don't think there's any huge differences. At least for simple settings I prefer Application Settings for the reasons in LeonG's answer.

I created a test app to explore as I've never bothered to look at Settings either. Here are some random findings.

Settings gives you an explicit property/name to reference in your code, but if you disassemble the compiled application, the getter is just looking up the value in its internal dictionary.
Settings get spat back out into your .config file in their own section. It would appear that you could just edit the .config file to change the value, but this isn't the case, kind of explained by the follwing point.
According to the documentation linked above, it seems the only way to get to the value is to use Properties.Settings.Default.myColor = Color.AliceBlue; but this always gives you the default value, which is compiled into your code as an attribute for the property. (I verified this using Reflector. The getter is tagged with the following: [ApplicationScopedSetting, DefaultSettingValue("asdf"), DebuggerNonUserCode]).
Settings are strongly typed. The compiler will take care of serialization of the objects automatically (this is only a few lines of code, though).

Overall, they seem EXTREMELY similar. The Settings dialog will give you a designer-y way to configure the values at design time, for what that's worth. It will also handle serialization for your as well. I'm sure there's some way to get the actual value instead of the default value, which would be a nice way to undo any user customizations if that's what you're storing (IE, instead of using the current value, just reference the Default value.) I don't currently know how to reference the current value, though.