.NET 桌面应用程序中的 Settings.settings 与 app.config
我对 Visual Studio 中存储和管理桌面应用程序设置的这两种机制的明显冗余感到非常困惑：
- 您可以使用 XML
app.config文件，将项目添加到ConfigurationManager类从代码中检索。 - 或者，您可以使用 Settings.settings 文件通过编辑器添加单独的设置。 Visual Studio 将生成一个
Settings类，以便在运行时以类型安全的方式检索设置。
这两种机制似乎具有相同（或几乎相同）的目的。我知道存在一些差异，但我也对重叠及其后果感到困惑。例如，当我使用 Visual Studio 将设置添加到 Settings.settings 文件中时，我输入的所有信息最终都会作为 app.config 文件中的条目，如下所示出色地。显然，存在同步机制：如果我更改 app.config 文件中的设置，Visual Studio 会提示我在下次打开 Settings.settings 文件时更新它在编辑器中。
我的问题是：
- 为什么有两种机制而不是一种？
- 在
Settings.settings上使用app.config的最常见场景是什么，反之亦然？ - 如果我的应用正在使用
Settings.settings，并且我在部署后更改了app.config中的值，会发生什么情况？Settings.settings不会发生同步，因为它已经被编译和分发。
笔记。我搜索过有关这个主题的问题，但我更困惑。例如，这个问题的答案非常矛盾，并且没有提供太多线索。
注意 2. 我知道 app.config 是一个设计时文件名，并且我熟悉 Visual Studio 将其复制并重命名到可执行文件夹的动态。
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.configfile, adding items to the<appSettings>section. These can be retrieved from code using theConfigurationManagerclass. - 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.
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.configoverSettings.settings, and vice versa? - What happens if my app is using
Settings.settingsand I change a value inapp.configafter it's been deployed? No syncronisation ofSettings.settingscan 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它们有不同的用途。设置 API 提供应用程序的读/写访问权限，而配置是只读的（除非您用代码编写文件）。
设置可以为每个用户或每个应用程序定义，并且被设计为易失性的。用户设置被写入用户配置文件存储中的隐藏文件夹，这是 UAC 允许的。
App.config 仅适用于每个应用程序。对 App.config 的更改不会自动生效。它需要重新启动或编写代码来刷新值。在 UAC 下，用户不允许写入应用程序目录（例如 Program Files），因此该文件应被视为静态只读。
您可以在桌面应用程序中使用“Settings”来存储用户首选项或在运行时更改的设置。
您可以使用 App.config 进行更通用的静态设置，例如连接字符串等，或者定义应用程序中使用的组件的配置。
如果应用程序被重新部署，那么它将采用新设置，除非计算机上已有用户/应用程序自定义，在这种情况下它将继续使用这些设置，除非你擦掉它们。
如果您添加新设置，这些设置将会被拾取。事实上，默认值已融入到 Settings 类中，因此即使 app.config 为空，Settings 仍然有效。
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.
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.
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.
从 .NET Framework 的角度来看（暂时不谈工具 - Visual Studio），历史上只有
[app.exe].config（事实上，它是 AppDomain 定义的作为配置文件，该名称由 AppDomain 定义，这就是为什么它是 Web 应用程序的web.config...）和machine.config。 “app”与应用程序一起部署，“machine”针对整个机器。对于普通用户来说，它们应该是“相当”只读的。改变它们是可能的，但这不是我们的想法。但是我怎样才能保存最终用户的偏好呢？这就是引入 [user].config 的原因（我相信是在 .NET 2 中）。官方文档是这样说的：
因此，从 .NET Framework 的角度来看，只有一种 3 层机制。
现在，Visual Studio 只是尝试通过为最终读/写设置生成类型安全代码来帮助您。大多数情况下，[user].config 文件不存在，并且设置值将由
DefaultSettingValueAttribute中的内容定义（为每个设置定义），或者使用应用程序中静态定义的内容.config。这就是 Visual Studio 还更新 app.config 文件的原因，以便您可以定义设置的静态默认值。但你可以完美删除所有 app.config 内容。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'sweb.configfor web apps...) andmachine.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:
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.