.NET 桌面应用程序中的 Settings.settings 与 app.config [英] Settings.settings vs. app.config in .NET desktop app

问题描述

可能的重复:
app.config有什么区别文件和 XYZ.settings 文件?

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

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

• 您可以使用 XML app.config 文件，将项目添加到 部分.这些可以使用 ConfigurationManager 类从代码中检索.
• 或者，您可以使用 Settings.settings 文件通过编辑器添加单个设置.Visual Studio 将生成一个 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.

这两种机制似乎服务于相同(或几乎相同)的目的.我知道存在一些差异，但我也对重叠及其后果感到困惑.例如，当我使用 Visual Studio 将设置添加到 Settings.settings 文件时，我放入的所有信息最终都会作为 app.config 文件中的条目作为好.显然，存在同步机制:如果我更改 app.config 文件中的设置，Visual Studio 会在我下次打开它时提示我更新 Settings.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.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.

我的问题是:

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

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

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

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.

推荐答案

从 .NET Framework 的角度来看(暂时不说工具 - Visual Studio -)，历史上只有 [app.exe].config(其实就是AppDomain定义的配置文件，名字是AppDomain定义的，所以对于web应用来说就是web.config...)和 machine.config.'app' 与应用程序一起部署，'machine' 用于整机.对于普通用户来说，它们应该是完全"只读的.可以改变它们，但这不是我们的想法.

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.

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

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:

最初与.NET一起发布的配置系统框架支持提供静态应用配置数据通过本地计算机的 machine.config 文件或在与应用程序一起部署的 app.exe.config 文件.这LocalFileSettingsProvider 类在以下方式:

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) 应用程序范围的设置可以存储在 machine.config 中或 app.exe.config 文件.Machine.config 始终是只读的，而app.exe.config 受安全考虑限制为只读适用于大多数应用程序.

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) 用户范围的设置可以存储在 app.exe.config 文件中，其中如果它们被视为静态默认值.

2) User-scoped settings can be stored in app.exe.config files, in which case they are treated as static defaults.

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

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 的角度来看，只有一个 3 层机制.

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

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

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.

这篇关于.NET 桌面应用程序中的 Settings.settings 与 app.config的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！