Settings.settings vs. app.config in .NET desktop app [duplicate]

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.

Answer 2

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.