何时使用？部分优于自定义配置部分？
创建应用程序或库的配置时，我通常更喜欢使用自定义配置部分而不是
- 框架序列化为用户定义的配置对象；每个配置值都有一个适当的类型
- 配置值可以根据属性的类型和值范围进行验证
鉴于此，我什么时候想使用松散类型的
When creating my application's or library's configuration, I generally prefer using a custom configuration section over the <appSettings> section for the following reasons.
- Framework serialization to a user-defined configuration object; each config value has an appropriate type
- Configuration values may be validated against type and value ranges with attributes
Given this, when would I want to use the loose-typed <add/> key/value mechanism of the <appSettings> section? As I recall, application-level configuration in this section can override existing machine-level configuration from machine.config. Is this the only case, or are there other reasons?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于快速而肮脏的应用程序来说更容易。
这与 ASP.NET 具有神奇的“Page_Load”方法之类的原因相同 - 无需显式连接，您可能不会在企业应用程序中使用它；它只是为 RAD 准备的。
It's easier for quick-and-dirty applications.
It's the same reason ASP.NET has things like the magic "Page_Load" method - no explicit wiring, you probably don't use it in an enterprise-y application; it's just there for RAD.
appSettings 标签有一个“file”属性，允许您将整个 appSettings 部分重定向到外部文件。例如，您可以为不同的环境拥有不同的 appSettings 实例：dev.config、qa.config 等。不过，我不确定您是否可以使用其他配置部分来做到这一点。
例子：
The appSettings tag has a "file" attribute that allows you to redirect your entire appSettings section to an external file. So for example you can have different appSettings instances for different environments: dev.config, qa.config, etc. I'm not sure if you can do that with other configuration sections though.
Example: