.NET 桌面应用程序中的 Settings.settings 与 app.config

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

提问by CesarGon

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

可能重复：
app.config 文件和 XYZ.settings 文件有什么区别？

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

我对 Visual Studio 中用于存储和管理桌面应用程序设置的这两种机制的明显冗余感到非常困惑：

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

• 您可以使用 XMLapp.config文件，将项目添加到该<appSettings>部分。这些可以使用ConfigurationManager类从代码中检索。
• 或者，您可以使用 Settings.settings 文件通过编辑器添加单个设置。Visual Studio 将生成一个Settings类，用于在运行时对设置进行类型安全的检索。

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.settingsfile, all the information that I put in ends up as entries in the app.configfile as well. Apparently, a synchronisation mechanism exists: if I change a setting in the app.configfile, Visual Studio prompts me to update the Settings.settingsfile next time I open it up in the editor.

这两种机制似乎服务于相同（或几乎相同）的目的。我知道存在一些差异，但我也对重叠及其后果感到困惑。例如，当我使用 Visual Studio 向Settings.settings文件添加设置时，我放入的所有信息最终app.config也会作为文件中的条目。显然，存在同步机制：如果我更改app.config文件中的设置，Visual Studio 会在我Settings.settings下次在编辑器中打开文件时提示我更新文件。

My questions are:

我的问题是：

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

• 为什么是两种机制而不是一种机制？
• 使用app.configover的最常见场景是什么Settings.settings，反之亦然？
• 如果我的应用程序正在使用Settings.settings并且我在app.config部署后更改了一个值，会发生什么情况？Settings.settings因为它已经被编译和分发，所以不会发生同步。

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

笔记。我已经搜索了有关此主题的问题，但我更加困惑。例如，这里对这个问题的回答非常矛盾，并没有说明什么。

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

注意 2. 我知道这app.config是一个设计时文件名，并且我熟悉 Visual Studio 将其复制并重命名到可执行文件夹的动态。

采纳答案by Simon Mourier

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

从 .NET Framework 的角度来看（暂时不说工具 - Visual Studio -），历史上只有[app.exe].config（实际上，这是 AppDomain 定义的配置文件。名称由 AppDomain 定义，即为什么它web.config适用于网络应用程序...）和machine.config. 'app' 与应用程序一起部署，'machine' 用于整机。对于普通用户来说，它们应该是“完全”只读的。改变它们是可能的，但这不是想法。

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:

但是我怎样才能保存最终用户的首选项呢？这就是引入 [user].config 的原因（我相信 .NET 2）。官方文档是这样说的：

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.

最初随 .NET Framework 一起发布的配置系统支持通过本地计算机的 machine.config 文件或随应用程序一起部署的 app.exe.config 文件提供静态应用程序配置数据。LocalFileSettingsProvider 类通过以下方式扩展了这种原生支持：

1) 应用程序范围的设置可以存储在 machine.config 或 app.exe.config 文件中。Machine.config 始终是只读的，而 app.exe.config 受安全考虑限制为大多数应用程序的只读。

2) 用户范围的设置可以存储在 app.exe.config 文件中，在这种情况下，它们被视为静态默认值。

3) 非默认用户范围设置存储在新文件 user.config 中，其中 user 是当前执行应用程序的人的用户名。您可以使用 DefaultSettingValueAttribute 为用户范围的设置指定默认值。因为用户范围的设置经常在应用程序执行期间更改，所以 user.config 始终是读/写的。

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

因此，从 .NET Framework 的角度来看，只有一种 3 层机制。

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.

现在，Visual Studio 只是尝试通过为最终读/写设置生成类型安全代码来帮助您。大多数情况下，[user].config 文件不存在，设置值将由DefaultSettingValueAttribute（为每个设置定义的）中的内容定义，或使用 app.config 中静态定义的内容。这就是为什么 Visual Studio 还会更新 app.config 文件，以便您可以为设置定义静态默认值。但是您可以完美地删除所有 app.config 内容。

回答by TheCodeKing

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

它们用于不同的目的。设置 API 提供来自应用程序的读/写访问，而配置是只读的（除非您在代码中编写文件）。

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.

可以为每个用户或每个应用程序定义设置，并且被设计为易变的。用户设置被写入用户配置文件存储中的隐藏文件夹，这是 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.

App.config 仅适用于每个应用程序。不会自动获取对 App.config 的更改。它需要重新启动或代码来刷新值。在 UAC 下，用户不允许写入程序文件等应用程序目录，因此该文件应被视为静态只读。

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

使用 app.config 而不是 Settings.settings 的最常见场景是什么，反之亦然？

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.

您可以将 App.config 用于更通用的静态设置，例如连接字符串等，或用于定义应用程序中使用的组件的配置。

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

如果我的应用程序使用 Settings.settings 并且我在部署后更改了 app.config 中的值，会发生什么情况？

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.

如果您添加新设置，这些将被选取。事实上，默认值被烘焙到设置类中，所以即使 app.config 为空，设置仍然有效。