AppSettings 与 applicationSettings 的优缺点（.NET app.config / Web.config）答案

【问题标题】：Pros and cons of AppSettings vs applicationSettings (.NET app.config / Web.config)AppSettings 与 applicationSettings 的优缺点（.NET app.config / Web.config）
【发布时间】：2010-10-02 10:26:16
【问题描述】：

在开发 .NET Windows 窗体应用程序时，我们可以在 App.config 标记之间进行选择来存储我们的配置值。哪个更好？

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

【问题讨论】：

在 MS 示例代码中，他们使用 appSettings msdn.microsoft.com/en-us/library/… 这让我感到困惑 :(
发现这篇文章 codeproject.com/KB/files/… 似乎暗示 appSettings 是用于 w/r 而 applicationSettings 是只读的。
另一篇相关的文章stackoverflow.com/questions/453161/…
注意同样适用于web.config，所以我在这个问题中添加了web.config标签。

标签： .net web-config app-config

【解决方案1】：

基本的<appSettings> 更容易处理 - 只需输入<add key="...." value="..." /> 条目即可。

缺点是：没有类型检查，例如您不能安全地假设您想要配置的号码确实有一个数字 - 有人可以在该设置中输入一个字符串.....您只需以 ConfigurationManager["(key)"] 访问它，然后由您决定自己是什么处理。

另外，随着时间的推移，<appSettings> 会变得相当复杂和混乱，如果您的应用程序的很多部分开始在其中放入东西（还记得旧的 windows.ini 文件吗？:-)）。

如果可以，我更愿意并推荐使用您自己的配置部分 - 使用 .NET 2.0，它真的变得非常简单，这样，您可以：

a) 在代码中定义您的配置设置并使其类型安全并检查了
b) 您可以清楚地将 YOUR 设置与所有人分开别人的。你也可以重复使用你的配置代码！

在 CodeProject 上有一系列非常好的文章来揭开 .NET 2.0 配置系统的神秘面纱：

强烈推荐！ Jon Rista 很好地解释了 .NET 2.0 中的配置系统。

【讨论】：

我发现 applicationSettings 更容易添加编辑和删除设置，而且您不必编写一行代码，而且它们是类型安全的，而且您可以将它们限定为用户或应用程序，因为您可以只需在 VS 中使用项目属性中的“设置”选项卡即可。

【解决方案2】：

应用程序设置可以通过设计器进行控制（默认情况下通常有一个 Settings.settings 文件），因此它更易于修改，并且您可以通过设置类以编程方式访问它们，它们看起来像一个强类型属性。您还可以进行应用程序和用户级别设置，以及回滚的默认设置。

这从 .NET 2.0 开始可用，并且不推荐使用其他方式（据我所知）。

更多详情请见：msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

【讨论】：

【解决方案3】：

要了解app.config 中设置的优点和缺点，我建议您查看两者的技术细节。我提供了链接，您可以在其中找到用于处理的源代码，并在下面描述更多技术细节。

让我简要总结一下我在与他们合作时所认识到的（注意：这同样适用于网站/网络应用程序的web.config 文件）：

applicationSettings in .NET
（点击上方查看源代码和技术细节）

优点

它们允许存储类型化数据，包括对象类型（通过serializeAs 属性）
它们有一个用户和应用范围，允许存储默认值
Visual Studio 的配置部分支持它们
非常支持长字符串和/或带有特殊字符的数据（例如，包含双引号的嵌入式 JSON 字符串）

缺点

用户设置存储在用户配置文件中的不同位置（具有神秘的路径），可能难以清理
应用程序运行时的范围设置是只读的（运行时只能更改用户范围设置）
由 Visual Studio 的设置设计器构建的读/写方法代码，不是由 3rd 方工具直接提供的（有关解决方法，请参见上面的链接）

AppSettings in .NET
更新：AppSettings in .NET Core
（点击上方查看源代码和技术详情）

优点

“重量轻”，即易于处理
应用程序运行时的读写访问
管理员可以在
Internet 信息服务 (IIS) 管理器
^{（功能视图 -> 应用程序设置，注意名称的图标具有误导性，因为它只能处理 AppSettings 而不能处理 ApplicationSettings)}

缺点

仅支持字符串数据；字符串长度和特殊字符有限制
他们没有用户范围
它们不支持默认值
Visual Studio 的配置部分不直接支持

【讨论】：

【解决方案4】：

我一直在使用我不久前发现的一种模式，在该模式中您使用基本的 xml 标记，但将设置包装在静态配置类中。所以 - 一个 DIY App.Settings。

DotNetPearls Static Config Pattern

如果你这样做，你可以：

为不同的环境（开发、测试、产品）使用不同的配置值集
为每个设置提供合理的默认值
控制值的定义和实例化方式

设置起来很繁琐，但性能很好，隐藏了对键名的引用，并且是强类型的。这种模式适用于未被应用程序更改的配置，尽管您也可以支持更改。

配置：

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

配置类：

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

【讨论】：

OP 是要知道使用 A 还是 B 最好。我看不出 C 怎么可能是一个有效的答案。
@bkqc 我想我可以说“使用 A 并考虑包装它”
但它仍然无法解释 A 或 B 中的哪一个最好，以及为什么甚至更好，每个优点和缺点。

【解决方案5】：

我喜欢使用更简单的版本来存储和访问单个值。

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

我编写了一个实用程序类，以允许默认值的类型安全方式访问值。如果未提供默认值，则会给出有用的异常消息。

您可以在这里查看/下载课程：

http://www.drewnoakes.com/code/util/app-settings-util/

【讨论】：

+1，它更简单，特别是如果您有多个程序集（设置通常每个程序集都有一个部分）。我有一个类似的助手类。顺便说一句，您的班级目前希望配置文件使用文化敏感字符串，这不是一件好事 - 例如应该是“Double.TryParse(s, NumberStyles.Any, CultureInfo.InvariantCulture, out result)”而不是“Double.TryParse(s, out result)”。同样对于 nitpick，MS 编码指南推荐 GetInt32、GetInt16、GetBoolean 而不是 GetInt、GetShort、GetBool。
这很好，但没有回答有关 AppSettings 优缺点的问题。
@Matt，优点是它更简单。缺点是它更简单。如果您只需要几个文字值（布尔值、整数、字符串等），那么这种方法最划算。如果您需要结构化数据、命名空间分离、支持 XSD 的验证/完成等，那么自定义部分可能更合适。另一种选择是完全忽略App.config 文件并使用您自己的配置文件。很多图书馆都是这样做的。想到了 NLog。
@DrewNoakes - 我同意你的看法。感谢您的澄清。

【解决方案6】：

使用 ApplicationSettings 的一大好处是通过 ClickOnce 部署应用程序，如 this page 中详细说明的那样。

基本上，如果设置的类型为 User 并且已从其默认值修改，则它会在每次更新时保持修改状态。如果设置的类型为 Application，则在更新应用程序时会自动覆盖它。

此外，在 VB.NET 中，可以通过简单地使用 My.Settings 访问 ApplicationSettings。从 GUI 的角度来看，它是最简单的设置配置。

【讨论】：