在创建我的应用程序或库的配置时,我通常更喜欢使用自定义配置部分而不是该<appSettings>
部分,原因如下。
- 框架序列化为用户定义的配置对象;每个配置值都有一个适当的类型
- 可以根据类型和具有属性的值范围验证配置值
鉴于此,我什么时候想使用该部分的松散类型<add/>
键/值机制<appSettings>
?我记得,本节中的应用程序级配置可以覆盖 machine.config 中现有的机器级配置。这是唯一的情况,还是有其他原因?
在创建我的应用程序或库的配置时,我通常更喜欢使用自定义配置部分而不是该<appSettings>
部分,原因如下。
鉴于此,我什么时候想使用该部分的松散类型<add/>
键/值机制<appSettings>
?我记得,本节中的应用程序级配置可以覆盖 machine.config 中现有的机器级配置。这是唯一的情况,还是有其他原因?
对于快速而肮脏的应用程序来说,它更容易。
这与 ASP.NET 具有神奇的“Page_Load”方法之类的东西的原因相同——没有显式连接,您可能不会在企业级应用程序中使用它;它只是为 RAD 准备的。
appSettings 标签有一个“文件”属性,允许您将整个 appSettings 部分重定向到外部文件。因此,例如,您可以为不同的环境使用不同的 appSettings 实例:dev.config、qa.config 等。不过,我不确定您是否可以使用其他配置部分来做到这一点。
例子:
<appSettings file="qa.config"/>