Question

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

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

然后，访问它们，如：

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

我将上面概述的方法称为“app.config”方法。我很少看到人们建议在项目中添加“设置”文件。我已经在网络上和堆栈溢出中看到了这么多次...我开始怀疑我是否遗漏了某些东西......因为我不确定为什么你使用这种方法而不是使用“设置” “档案。在VS2005之前我没有进入.NET，所以我有一个理论就是VS2003中的事情是如何完成的，人们从未切换过？

推荐app.config方法的人的例子：

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

与AppSettings或Properties：custom configuration sections相比，有第三种，更好的方法。 AppSettings的优势：

1）强类型访问

2）架构和表单的内置验证机制。

3）基于POCO使其高度可测试 - 只需新建一个自己的测试配置。

4）不依赖魔术弦。并不是说你不能轻易地将AppSettings包装在一个类中并以这种方式访问它，但95％的开发人员都不这样做。

5）一旦你进入十几个设置，配置中的XML变得更加清晰。也比预设比特恕我直言更容易理解。

6）不依赖视觉工作室使其运作良好。

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

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

_____协助部分

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

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

2）当您加载配置节时，如果应用程序没有公开必要的信息或不正确的信息，它将抛出配置异常。与粘贴app.config或web.config时相同。还有一些我没有使用过的验证基础设施，因为我喜欢尽早或根本没有失败。

3）POCO是一个普通的旧C＃对象，以防有人错过了最近几年。无论如何，因为配置设置是装饰性的并且通过属性声明，所以您可以轻松测试配置设置，因为您只需要根据需要指定新的MyConfigSection（）并设置属性等。据我了解属性，你需要在那里配置正确的xml配置文件，否则你就是sol。其他优点是自定义配置部分可以处理您可以使用POCO完成的所有其他整洁的东西，例如接口和依赖注入。

4）没错，属性和自定义配置部分都是强类型的，AppSettings则不是。 AppSettings不好，道具/ CC好。

5）真正针对AppSettings。我在配置中继承了几页<add name="foo" value="bar" />的应用程序。与属性吐出的xml jibberish相比，这很容易。另一方面，您的自定义配置部分可能是相当语义和自我解释，因为您声明了部分名称和属性。我可以很容易地在生产服务器上的记事本中对它进行编辑，并且不要太担心自己在脚下蹲下来。

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

Answer 3

没有讨论，答案是：

“因为它更容易。”

Answer 4

两种情况：

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

这里的“设置”方法胜出了手。

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

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

Answer 5

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

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

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

更新

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

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

Answer 6

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

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

Answer 7

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

Win XP：c：\ Documents and Settings \％Username％\ Local Settings \ Application Data {Publisher Name} \

Win 7：C：\ Users \％用户名％\ AppData \ Local {Publisher Name} \

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

为什么人们一直建议使用appConfig而不是使用设置文件？（。净）

7 个答案:

为什么人们一直建议使用appConfig而不是使用设置文件？ （。净）

7 个答案:

为什么人们一直建议使用appConfig而不是使用设置文件？（。净）