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

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

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

From a .NET Framework point of view (not speaking of tools - Visual Studio - for the moment), historically, there was only [app.exe].config (in fact, it's what the AppDomain defines as the configuration file. The name is defined by the AppDomain, that's why it's web.config for web apps...) and machine.config. 'app' is deployed together with the application, 'machine' is for the whole machine. They were supposed to be 'quite' read-only for the average user. It's possible to change them, but it was not the idea.

But how can I save end user preferences then? That's why [user].config was introduced (I believe with .NET 2). The official documentation says this:

> The configuration system that was originally released with the .NET > Framework supports providing static application configuration data > through either the local computer's machine.config file or within an > app.exe.config file that you deploy with your application. The > LocalFileSettingsProvider class expands this native support in the > following ways: > > 1) Application-scoped settings can be stored in either the machine.config > or app.exe.config files. Machine.config is always read-only, while > app.exe.config is restricted by security considerations to read-only > for most applications. > > 2) User-scoped settings can be stored in app.exe.config files, in which > case they are treated as static defaults. > > 3) Non-default user-scoped settings are stored in a new file, > user.config, where user is the user name of the person currently > executing the application. You can specify a default for a user-scoped > setting with DefaultSettingValueAttribute. Because user-scoped > settings often change during application execution, user.config is > always read/write.

So from a .NET Framework point of view, there is only one 3-layer mechanism.

Now, Visual Studio just tries to help you by generating the type-safe code for the final read/write settings. Most of the time, that [user].config file does not exists and a setting value will be defined by what's in the DefaultSettingValueAttribute (defined for each setting), or use what's been defined statically in the app.config. That's why Visual Studio also updates the app.config file so you can define static defaults to the settings. But you can perfectly delete all that app.config stuff.