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.
Answer
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.