为什么人们一致推荐使用 appConfig 而不是使用设置文件？ （。网）

Question

我经常看到这样的问题的答案：“我应该如何在我的 .NET 应用程序中存储设置？” 是通过手动向 app.config（或 web.config）添加条目来编辑 app.config 文件，如下所示：

<configuration> 
  <appSettings>
    **<add key="ConfigValueName" value="ABC"/>**
  </appSettings>
</configuration>

然后，按如下方式访问它们：

string configValue = Configuration.AppSettings["ConfigValueName"];

我将把上面概述的方法称为“app.config”方法。 我很少看到人们建议向项目添加“设置”文件。 我已经在网络和 stackoverflow 上看到过很多次了……我开始怀疑我是否遗漏了一些东西……因为我不确定为什么你会使用这种方法而不是使用“设置” “ 文件。 我直到 VS2005 才开始接触 .NET，所以我的一个理论是，这就是 VS2003 中的工作方式，人们从未切换过？

人们推荐 app.config 方法的示例：

• 在 Windows 窗体 C# 应用程序中拥有配置文件的最简单方法
• 最佳实践：我应该如何在 C# 中存储设置（格式/类型）？

从我的角度来看，“设置文件”方法有以下优点：

1. 可用于同一界面中的应用程序设置（所有用户共用的设置）和用户设置。
2. 能够使用 Visual Studio 中的设置设计器支持。 恕我直言，比直接编辑 XML 文件更不容易出错。
3. 重构 - 您可以重命名特定的设置名称，它将自动更新代码中的引用。
4. 编译类型检查。
5. 自动完成支持。
6. 属性网格功能。 我发现 PropertyGrid 控件是制作快速选项表单的非常简单的方法。 您只需执行 propertyGrid1.SelectedObject = Settings1.Default; 即可完成。

如果您不确定“设置”文件方法的含义，请参阅此post 这是有人建议使用设置文件而不是 app.confg 的少数示例之一。

编辑：请理解：本主题的目的是弄清楚为什么人们会使用上面概述的 app.config 方法而不是设置文件方法。 我遇到了设置文件方法的局限性，有时被迫推出自己的自定义解决方案。 这是一个完全不同的讨论。

Answer 1

如果没有讨论，那么答案就是：

“因为它更容易。”

Answer 2

两种情况：

• 客户端应用程序附带的配置设置设置为默认值。 该应用程序提供了一个 UI 来修改单个用户或所有用户的设置。

在这里，“设置”方法轻而易举地获胜。

• 一个应用程序由几个相对独立的程序集组成，每个程序集都需要一些简单的配置设置。 这些设置通常由管理员设置，应用程序部署后不会对其进行修改。

这里“appSettings”可以更简单地管理。 通过“设置”方法，每个可配置程序集都会有一个部分添加到主应用程序的配置文件中。

Answer 3

因为设置文件基础结构 (1) 更复杂，(2) 鉴于其复杂性，记录不充分。

设置文件的默认工作方式对于小型应用程序很有用。 对于较大的，您经常需要更改此默认值。 设置文件基础设施可以满足您的需求，但即使有良好的文档，也有一个陡峭的学习曲线。 如果没有文档，它几乎毫无用处。

我只是参考这个文章结束。 请随意粘贴一些有用的链接到概念性 MSDN 文档来反驳我的论点。

---

更新：

我需要公平地提供一个我没有找到记录的特定用例：

我喜欢应用程序设置设计器。 我还喜欢存储设置的 XML 格式。 我想保留这些功能，但使用其他位置来存储设置。 我没有找到任何提示是否支持此用例，如果支持，如何完成任务。

Answer 4

不正确：设置文件方法的部分问题在于它要求应用程序位于特定位置并且设置文件位于正确位置。 如果其中之一被意外移动，则设置可能会永久丢失，就像被删除一样。 还可能存在文件夹中存在多个同名设置文件的问题，导致其中一个设置文件被覆盖。 如果软件依赖于设置文件，这尤其糟糕。 这些问题对于已安装的软件来说并不那么明显，但对于未安装但只是下载并运行的软件来说可能是一个主要问题。 想象一下，如果有人将其中几个程序下载到同一目录，并且它们都使用相同的设置文件名。

编辑：正如与提出问题的人讨论的那样，这个答案是不正确的，因为该问题指的是保存到设置文件的两种不同方式。 当我给出答案时，我认为他指的是两个不同的文件。 我能提供的唯一另一个答案是，这是个人喜好的问题。

Answer 5

我还想指出 app.Config 和“设置”窗口之间的一个区别。
如果您在“设置”下保存任何内容，则设置将保存在以下位置。

Win XP: c:\Documents and Settings\%Username%\Local Settings\Application Data{Publisher Name}\

Win 7: C:\Users\%Username%\AppData\Local{Publisher Name}\

而 app.config 设置仅保存在配置文件中。

Answer 6

我认为两者之间最大的区别是应用程序无法更改app.config中的值。 这些值是在运行时读取的，并且没有内置支持将新值写入配置文件。

可以使用Save()命令更改设置文件。

对设置文件的内置支持的一个主要问题是设置文件的存储位置。 如果您查看 APPDATA 文件夹，您会发现有一个包含公司名称的文件夹，然后是一个包含产品名称的子文件夹，然后是一个包含半随机名称和版本信息的子文件夹。

每当您发布新版本时，由于设置文件的存储位置，它都不会找到以前版本中的设置文件。 也无法更改设置文件的存储位置。

我在一个项目中使用了它，发现创建我自己的使用 XML 文件进行设置的 AppSettings 类更有用。 我可以控制文件的格式和位置。

Answer 7

还有第三种方法，也是比 AppSettings 或 Properties 更好的方法：自定义配置部分。 相对于 AppSettings 的优点：

1) 强类型访问

2) 针对架构和表单的内置验证机制。

3）基于POCO，使其具有高度可测试性——只需新建您自己的测试配置。

4）不依赖魔法弦。 并不是说您不能轻松地将 AppSettings 包装在类中并以这种方式访问​​它，但 95% 的开发人员不这样做。

5) 一旦您获得十几个左右的设置，配置中的 XML 就会变得更加容易理解。 恕我直言，它也比属性位更容易理解。

6) 不依赖 Visual Studio 来使其正常工作。

诚然，我从未真正使用过属性，因为我首先接触了自定义配置部分。

顺便说一句，如果您还没有听说过这些，那么您仍然每天都在使用它们——您认为 .NET 配置文件中的标准配置部分是什么？

_____澄清部分

首先，其中大部分内容是针对 AppConfig 方法的，重读后我并不清楚。 我认为我们通常站在同一边——避免使用松散的名称值包进行配置，因为它太容易损坏。 我还应该补充一点，我是一个网络人员，所以对我来说，用户设置是存在于应用程序层而不是配置中的东西。

1）确实，属性和自定义配置部分都具有强类型访问。 应用程序设置没有。 AppSettings 不好，Props/CC 好。

2）当加载配置节时，如果没有暴露必要的信息或不正确的信息，应用程序将抛出配置异常。 就像你搞乱了 app.config 或 web.config 一样。 我还没有使用更多的验证基础设施，因为我喜欢尽早失败或根本不失败。

3) POCO 是普通的旧 C# 对象，以防有人错过了过去几年的情况。 无论如何，由于配置设置是装饰性的并通过属性声明，因此您的配置设置可以轻松测试，因为您只需要指定一个新的 MyConfigSection() 并根据需要设置属性等。 据我了解属性，您需要有配置文件，其中包含正确的 xml，否则您就是 sol. 其他优点是自定义配置部分可以与您可以使用 POCO 执行的所有其他巧妙操作一起使用，例如接口和依赖项注入。

4）确实，Properties 和自定义配置部分都是强类型的，而 AppSettings 则不是。 AppSettings 不好，Props/CC 好。

5）真正针对AppSettings。 我继承了一些应用程序，在配置中只有 2 页 。 与属性吐出的 xml 乱码相比，这很容易。 另一方面，您的自定义配置部分可能相当语义化且不言自明，因为您正在声明部分名称和属性。 我可以很容易地在生产服务器上的记事本中编辑它，而不必担心在紧要关头搬起石头砸自己的脚。

因此，除了没有基于 VS 的属性网格（我认为这是一件坏事——为什么需要网格来编辑配置？）之外，与属性相比，自定义配置部分有很多优点，并且没有真正的缺点。 自定义配置部分和属性都比 AppSettings 具有巨大的优势。