When to use .NET Settings vs config <appsettings>?

Question

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.

Answer 1

Hi,

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!

Answer 2

I use .config file settings (web.config) for pretty much everything that could change after compile & release of the code. It's nice because you can change it easily. I'm not familiar with applications settings, but it looks like those you might have to recompile the application if you changed one.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.