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

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.

Barbera

In addition to Simon's excellent answer below, see Ruben's answer to a similar question. – Arda

Answer 1

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.

Demobilize

Thanks, Simon. For what kind of scenario would you suggest to use each of the two mechanisms? – Barbera

For end-user settings, I use [user].config. For other 'static' settings, I use [app].config. All with defaults so I don't in fact need none of these (the first time I ship, I don't ship any file) – Demobilize

Simon, the question asks about Settings.settings file, and Visual Studio's Settings class. I'm not seeing in your answer how those two are handled. Instead you mention user.config. Are the two "settings" concepts related to user.config? Or are they from an older or newer alternative mechanism? – Arda

Found an answer in a comment under Ruben's answer - .settings gets compiled into user's .config. Is that correct? – Arda

@Arda - Settings are a global concept. Each setting has a scope. user-scoped settings can be saved. When they are saved, it's written to user.config. – Demobilize

This answer feels very unsatisfactory to me because it doesn't even mention Settings.settings. – Orford

It sounds to me that Settings.settings takes precedence over app.config. That is to say, if the values are different then the values in Settings.settings are the ones that are used. Why then does Visual Studio offer to change Settings.settings to match app.config and not the other way around? – Orford

@KyleDelaney - Settings.settings is just the default .settings file, named "Settings", you can create more, of these "Application settings". You can ask your own questions. – Demobilize

If I asked this question again it would be marked as a duplicate of both this one and the one it's marked as a duplicate of. – Orford

Answer 2

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.

Hiltan

Thanks for your detailed answer. Still, I am confused about a few points. First, I don't agree that you cannot write to the app.config file; the ConfigurationManager class provides write access to any config file, and it can select user-specific configurations as well (msdn.microsoft.com/en-us/library/ms134265.aspx). I am also confused about the scenarios that you use as examples. Would you, for instance, store a connection string in Settings or app.config? Why? Regarding my third question, it is about changing the values of settings (rather than adding or removing settings)... – Barbera

...once the app has been deployed, i.e. when it is in production. I don't want to recompile and redeploy the app. For example, if my database moves to a new server, I want to just change the server name in the config file, restart the app and keep working; that's the whole point of config files, right? In this scenario, what would happen to the value stored in the Settings file? Would it be discarded/superseded/ignored? Thanks. – Barbera

Yes it's possible to update web.config using configuration manager but you have to change the deployed file, which would usually be locked down for UAC. It's not designed for runtime changes, whereas settings is. Changes to settings are saved to the User profile folder so there are no permissions issues. You would store connection string in app.config as it's a static setting. If you had a customised version of a setting, it's stored elsewhere so deploying a new update would have no affect. The customised value would continue to override, hence again why app.config is better for conn strings. – Hiltan

Please note that I am talking about desktop apps, so web.config is irrelevant here. – Barbera

Sorry I meant app.config - wrote that too early in the morning. – Hiltan

You say that app.config is not designed for runtime changes but settings is. How is that so? I've been toying with some test projects and it's easy to change app.config contents while the app is running, and the app gets fresh values as long as you call ConfigurationManager.RefreshSection() before reading values. Also, when you say that settings are designed for runtime changes and are saved to the user profile folder, where are they saved to? What specific folder? I couldn't find any user files under my profile folder for my app settings. Thanks. – Barbera

Nice down vote. Settings are deployed to user profile folder, see here, which is permitted under UAC. Applications app.config and even application scoped settings are considered readonly because the user is not permitted write to the application directory (such as program files) under UAC. Hence why app.config is not designed for run time changes, but settings are. I'm not saying its not possible to write to app.config, it's just bad practice and won't work in the real world unless you elevate the app. – Hiltan

Sorry if my downvote disappointed you; I appreciate your help, but I find the answer to be incomplete and misguided so far. I was expecting a straightforward answer and/or pointer to documentation rather than a long stream of comments. Anyway, and regarding writing to app.config, I don't agree: you are assuming that it is the app who writes to it, but I never said that. The app.config is typically altered by an administrator that, for example, updates a connection string long after the app was originally deployed. Of course users couldn't do it. I think this is a perfectly OK scenario. – Barbera

So your down vote is your way of thanking me for the time and effort I have spent answering your questions? You seem to know better, so be it. – Hiltan

No, it is my way to signal that the answer is incomplete and misguided, as I said. Also, as I said, I do appreciate your efforts and attention. But it's OK, I've lifted the downvote since it seems so important to you. Let's forget it, shall we? – Barbera

There nothing misguided in the answer. You asked why there are two mechanisms and I explained this several times now. Read up on UAC. I would point you at some documentation but it's quite scarce. If you still don't accept my answer create your own and mark it as correct. – Hiltan