Settings.settings vs. app.config in .NET desktop app

Question

Possible Duplicate:
What is the difference between app.config file and XYZ.settings file?

I am quite confused by the apparent redundancy of these two mechanisms in Visual Studio to store and manage desktop application settings:

• You can use the XML app.config file, adding items to the <appSettings> section. These can be retrieved from code using the ConfigurationManager class.
• Alternatively, you can use the Settings.settings file to add individual settings through an editor. Visual Studio will generate a Settings class for type-safe retrieval of settings at run-time.

These two mechanisms seem to serve the same (or nearly the same) purpose. I am aware there are some differences, but I am also puzzled by the overlap and its consequences. For example, when I use Visual Studio to add settings to the Settings.settings file, all the information that I put in ends up as entries in the app.config file as well. Apparently, a synchronisation mechanism exists: if I change a setting in the app.config file, Visual Studio prompts me to update the Settings.settings file next time I open it up in the editor.

My questions are:

• Why two mechanisms and not just one?
• What are the most common scenarios for using app.config over Settings.settings, and vice versa?
• What happens if my app is using Settings.settings and I change a value in app.config after it's been deployed? No syncronisation of Settings.settings can happen since it's already been compiled and distributed.

Note. I have searched for questions on this topic, but I am even more confused. For example, answers to this question here are quite contradictory and do not shed much light.

Note 2. I am aware that app.config is a design-time file name, and I am familiar with the dynamics of Visual Studio copying and renaming it to the executable folder.

Answer 1

Why two mechanisms and not just one?

They serve different purposes. The settings API offers read/write access from the application, whereas config is read only (unless you write the file in code).

Settings can be defined per user or per application, and are designed to be volatile. User settings are written to hidden folder within User Profile storage which is permitted under UAC.

App.config is per application only. Changes to App.config aren't automatically picked up. It requires restart or code to refresh the values. Under UAC users are not permitted to write to the application directories such as Program Files, so this file should be considered static readonly.

What are the most common scenarios for using app.config over Settings.settings, and vice versa?

You could use Settings in a desktop application for storing user preferences, or settings that change at runtime.

You would use App.config for more generic static settings, like connection strings etc, or for defining the configuration of components used within your app.

What happens if my app is using Settings.settings and I change a value in app.config after it's been deployed?

If the application is redeployed then it will pick up the new settings, unless there are user/app customisations on the machine already in which case it will continue to use those, unless you wipe them.

If you add new settings, these will get picked up. In fact the default values are baked into the Settings class, so even if the app.config is empty the Settings still function.