28

我经常看到这样的问题的答案：“我应该如何在我的 .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 方法的示例：

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

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

如果您不确定我所说的“设置”文件方法是什么意思，请参阅这篇文章，这是有人建议使用设置文件而不是 app.confg 的少数示例之一。

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

4

7 回答 7

23

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

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

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

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

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

于 2009-06-19T07:17:01.293 回答
13

还有比 AppSettings 或 Properties 更好的第三种方法：自定义配置部分。与 AppSettings 相比的优势：

1）强类型访问

2) 模式和表单的内置验证机制。

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

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

5) 一旦你进行了十几个设置，配置中的 XML 就会变得更容易理解。也比属性位恕我直言更容易理解。

6）不依赖视觉工作室使其正常工作。

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

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

_____澄清部分

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

1) 没错，属性和自定义配置部分都具有强类型访问权限。AppSettings 没有。AppSettings 不好，Props/CC 好。

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

3) POCO 是普通的旧 C# 对象，以防有人错过了过去几年。无论如何，因为配置设置是装饰性的并通过属性声明，所以您的配置设置可以很容易地测试，因为您只需要删除一个新的 MyConfigSection() 并根据需要设置属性等。据我了解属性，您需要在其中拥有带有正确 xml 的配置文件，否则您就是 sol.xml。另一个优点是自定义配置部分可以与你可以用 POCO 做的所有其他简洁的东西一起使用，比如接口和依赖注入。

4) 是的，属性和自定义配置部分都是强类型的，AppSettings 不是。AppSettings 不好，Props/CC 好。

5）真正针对AppSettings。我继承了一些应用程序，<add name="foo" value="bar" />配置中只有 2 页。与属性吐出的 xml 乱码相比，这很容易。另一方面，您的自定义配置部分可以是相当语义化和不言自明的，因为您要声明部分名称和属性。我可以很容易地在生产服务器上的记事本中对其进行编辑，并且在紧要关头开枪打自己的脚时不会太紧张。

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

于 2009-06-19T12:20:31.773 回答
2

不讨论，那么答案是：

“因为它更容易。”

于 2009-06-19T07:47:57.143 回答
1

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

默认情况下，设置文件的工作方式对小型应用程序很有用。对于较大的，您通常需要更改此默认值。设置文件基础架构可以满足您的需求，但即使有良好的文档，也会涉及陡峭的学习曲线。没有文档，它几乎是无用的。

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

更新：

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

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

于 2013-02-21T07:42:26.827 回答
1

两种情况：

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

在这里，“设置”方法赢得了胜利。

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

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

于 2009-06-19T11:48:59.483 回答
0

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

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

于 2009-06-19T07:20:41.567 回答
0

我还想指出 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 设置仅保存在配置文件中。

于 2012-04-17T20:03:24.077 回答