appSettings vs applicationSettings。appSettings过时了吗？

Question

关于在web.config中保存设置的两种方法，我有一些问题。

应用程序设置：在web.config中查找

<appSettings>
 <add key="key1" value="value1"/>
 <add key="key2" value="value2"/>
</appSettings>

代码隐藏中的使用

ConfigurationManager.AppSettings["key1"];

应用程序设置/属性(使用项目中的‘属性’-选项卡自动生成)

Look in web.config

<applicationSettings>
    <Projectname.Properties.Settings>
        <setting name="TestEnvironment" serializeAs="String">
            <value>True</value>
        </setting>
    </Projectname.Properties.Settings>
</applicationSettings>

代码隐藏中的使用

Properties.Settings.Default.TestEnvironment

那么，web.config中设置的这两种存储可能性有什么不同呢？

据我所知，appSettings的一个缺点是您自己修改了web.config，并且appSettings不是强类型的，而applicationSettings是强类型的。

两者都可以在web部署项目中替换。

就我而言，appSettings没有任何用处。我是不是漏掉了什么？哪个是历史上看起来更老的？

Answer 1

这在这里已经讨论过了：Pros and cons of appSettings vs applicationSettings (.NET app.config)。

至于你的问题:较早的是<appSettings>，它大约在2.0之前，<applicationSettings>在2.0中可用。

优势？当我在服务器上编辑值或添加值时，最好的工具是记事本<applicationSettings> is very verbose，有时我只想要一个字符串。也许是一个愚蠢的例子，但当我调整各层之间的配置设置以正确地进行自动部署设置时，它非常有用，因为它很简单。

不过，我不得不同意另一个讨论中的marc_s，如果你正在做任何真正复杂的事情，你可能已经到了应该有自己的配置节的地步了。由于您在startup...you上反序列化到您的配置类型中，以这种方式获得相同的类型检查，因此直接通过XML串行化器是唯一的区别。

这也有一个好处，那就是我可以使用Config.LDAPServer，或者像Security.Config和Themes.Config这样的不同领域分别使用一种配置(猜想在这里！)，你可以得到一个非常有用/清晰的命名方案作为附带好处。

Answer 2

超时是命名空间的，因此两个不同的程序集都可以有一个“ApplicationSettings”设置而不会发生冲突，而ApplicationSettings是可选的，因为默认值是通过代码中设置的属性来设置的。

Answer 3

我注意到的一件事是，aspx页面中的AppSettings值可以通过<%$ AppSettings: name %>内联标签引用，但似乎没有通过内联标签访问ApplicationSettings值的等效方法。