何时使用 .NET 设置与配置？
是否有关于何时使用应用程序设置的建议（不是每个用户设置）与 .config 文件
更新
希望了解一些更细微和重要的差异，因为它们都是有效的键/值存储。 例如，我知道修改 web.config 中的 appsettings 会回收 Web 应用程序。
设置已经在 .NET 中存在一段时间了，我没有费心去查看它们 - 也许其中一个有点多余，或者同时使用两者没有意义......这就是我想要的细节寻求理解和原因。
Are there any recommendations on when to use Application settings (not per user settings) vs. .config file <appsettings>?
Update
Looking to understand some of the finer and important differences because they're both effectively key/value stores.
For example, I know modifying appsettings in web.config will recycle the web application.
Settings have been in .NET for a while now and I haven't bothered to look at them - maybe one is somewhat redundant, or using both at the same time doesn't make sense... that's the kind of detail I'm looking to understand and the reasons.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
这个问题有点老了，但我偶然发现了它，并想增加一些清晰度，以防其他人也偶然发现它......
设置选项（而不是原始的部分）在框架中拥有强大的支持：
设置是强类型的（即 bool、int、ConnectionString 等），而不是全部作为字符串返回，以便在需要时由代码解析。
设置是
设置的范围可以是 a) 内部或公共，以及 b) 每用户或每应用程序（后者本质上是指每台机器）。
您的应用程序需要提供自己的接口来更改设置，但这相当简单，因为设置属性是在代码中读/写的，并且生成的类提供了保存更改的功能。
部署的 app.config （或 web.config）文件仅存储默认值（有关如何处理运行时更改的信息，请参阅下文） - 这意味着更改设置并在运行时保存它们不会更改 .配置文件 - 并且扩展后不会导致应用程序重新启动。
运行时的更改将保存到本地位置（c:\ProgramData.. 或 c:\Users\MyUser\AppData\Local.. 中的某个位置），具体取决于所选范围。因此，应用程序的后续版本可以安全地引入新设置，而不必担心破坏以前自定义的值，因为它们被安全地存储起来。
希望这有助于澄清一些事情。
The question is a bit old but I stumbled upon it and thought to add some clarity in case someone else also stumbles upon it...
The settings option (as opposed to the raw <appSettings> section) has strong support in the framework:
Settings are strongly typed (i.e. bool, int, ConnectionString, etc) instead of all being returned as string to be parsed by your code if needs be.
Settings can be scoped to be a) Internal or Public, and b) Per User or Per Application (the latter essentially meaning Per Machine).
Your application would need to supply its own interface for changing the settings, but that's fairly trivial as the setting properties are read/write in code, and the generated class supplies functionality for saving the changes.
The app.config (or web.config) file that is deployed, only stores the default values (see below for how runtime changes are handled) - which means that changing settings and saving them at runtime doesn't change the .config file - and by extension doesn't cause a restart of your application.
Changes at runtime are saved to a local location (somewhere in either c:\ProgramData.. or c:\Users\MyUser\AppData\Local..) depending on the scope chosen. As such, subsequent releases of your application can safely introduce new settings without fear of trashing previously customized values, as they are safely stored away.
Hope that helps to clear things up a bit.
到目前为止，从答案中似乎忽略了一点，.config 文件可以使用 转换文件。默认情况下，这些可用于 Web.config 文件（在 Visual Studio 中），并可通过 SlowCheetah - Visual Studio 的 XML 转换 加载项（SlowCheetah 还添加了预览器并在构建上应用转换，而不仅仅是在部署上嗯>。
One point that seems to be overlooked from the answers so far is that .config files can be transformed using Transformation files. These are available for Web.config files by default (in Visual Studio) and are enabled for arbitrary .config files with the SlowCheetah - XML Transforms add-in for Visual Studio (SlowCheetah also adds a previewer and applies transformations on build rather than just on deploy.
应用程序设置和配置文件 appSettings 部分仅限于键值对，这对于简单设置很有用，但如果您需要更强大的数据持久性，您可能会考虑为应用程序创建自定义配置部分。这是有关创建自定义配置部分的 stackoverflow 文章，
尽情享受吧！
Application settings and config file appSettings sections are limited to key value pairs, which are good for simple settings, but if you need a data persistence that is more robust you might look at creating a custom configuration section for your application. Here is stackoverflow article on creating a custom config section
Enjoy!
可以键入应用程序设置，这与应用程序设置相比是一个优点。
访问它们的方式（属性）比从数组获取值更简洁。
您可以使用该接口来实现将设置存储在数据库中的设置类。
Application settings can be typed, which is a plus compared to appsettings.
And the way you can access them is a little more neat (property) then getting a value from an array.
And you can use the interface to implement a settings class that stores you settings in a database.
需要注意的一件事是，如果您通过 ClickOnce 进行部署，尽管配置文件现在是可写的，但它们不在 ClickOnce 部署的应用程序中，因为这会填满文件哈希值。
因此，经验法则是任何环境配置都放在 app.config 中。任何用户配置都在“设置”中。
有时这条线有点模糊，所以对于那些模糊的线，我会包装在静态访问器方法中，以便您可以随意移动它们。
One thing to be aware of is, if you're deploying via ClickOnce despite the fact that config files are now writable they are not in a ClickOnce deployed app since that'll stuff with it's file hashes.
Therefore, the rule of thumb is that anything that's environment configuration goes in app.config. Anything that's user configuration goes in Settings.
Sometimes the line is a little fuzzy so for those fuzzy ones I would wrap in a static accessor method so that you can move them around at will.
我之前做过的事情是创建一个类，其中包含适合要保留的设置的属性。然后，类实例被 XML 序列化为文件，并且稍后可以反序列化以返回相同的对象，属性值保持不变。并且应用程序不需要回收，如果写入 web.config/app.config 文件则需要回收。
您可以通过这种方式获取强类型的应用程序设置，而不必担心键和值。当我想在应用程序中提供用户可设置的选项时，这对我来说非常有效。
Something I've done before is to create a class that contains properties appropriate to the settings to be persisted. A class instance is then XML serialized to a file, and can later be deserialized to get back the same object, property values intact. And the application will not need to be recycled, which it would if you write to the web.config/app.config file.
You can get strongly-typed application settings this way, and don't have to worry about keys and values. This has worked fairly well for me when I wanted to provide user-settable options within the application.
应用程序设置不会编译到程序集中。
我不确定，但我认为应用程序设置默认值已编译到程序集中，但可以在配置文件中覆盖这些值。
我认为应用程序设置是作为一种更友好的方式创建的，尤其是来自 VB.Net，但我不认为有任何巨大的差异。至少对于简单的设置，我更喜欢应用程序设置，原因在 LeonG 的答案中。
Application Settings do not get compiled into the assembly.
I'm not sure but I think that the Application Settings default values are compiled into the assembly, but these can be overridden in the config file.
I think Application Settings was created as a more friendly way of doing it, especially from VB.Net, but I don't think there's any huge differences. At least for simple settings I prefer Application Settings for the reasons in LeonG's answer.
我创建了一个测试应用程序来探索，因为我也从来没有费心去查看“设置”。以下是一些随机发现。
Properties.Settings.Default.myColor = Color.AliceBlue;但这总是为您提供默认值，即作为属性的属性编译到您的代码中。 （我使用 Reflector 验证了这一点。getter 标记有以下内容：[ApplicationScopedSetting, DefaultSettingValue("asdf"), DebuggerNonUserCode]）。总的来说，它们看起来非常相似。 “设置”对话框将为您提供一种设计者在设计时配置值的方法，以实现其价值。它还将为您处理序列化。我确信有某种方法可以获取实际值而不是默认值，如果这就是您要存储的内容，这将是撤消任何用户自定义的好方法（即，不使用当前值，只需引用默认值）值。）不过，我目前不知道如何引用当前值。
I created a test app to explore as I've never bothered to look at Settings either. Here are some random findings.
Properties.Settings.Default.myColor = Color.AliceBlue;but this always gives you the default value, which is compiled into your code as an attribute for the property. (I verified this using Reflector. The getter is tagged with the following:[ApplicationScopedSetting, DefaultSettingValue("asdf"), DebuggerNonUserCode]).Overall, they seem EXTREMELY similar. The Settings dialog will give you a designer-y way to configure the values at design time, for what that's worth. It will also handle serialization for your as well. I'm sure there's some way to get the actual value instead of the default value, which would be a nice way to undo any user customizations if that's what you're storing (IE, instead of using the current value, just reference the Default value.) I don't currently know how to reference the current value, though.