我目前正在完成由其他人启动的应用程序。他正在使用app.config进行一些设置，并为其他部分使用自定义xml文件。这迫使我坚持下去，并且我想将配置整合到一个文件中。为什么使用app.config来存储配置数据？
但我不确定是否将所有内容都移动到了app.config文件中，并抛出定制的xml文件，或者将所有内容移动到另一个文件中，而忘记了app.config。
我可以看到两个参数，一个用于每个选项：
但我敢肯定，有一个事情比很多我现在可以想到。这就是为什么我问：
使用app.config存储配置与“传统”配置文件的优缺点是什么？
使用app.config的主要好处是它是.NET应用程序存储其配置的默认支持方式。任何人使用该应用程序或有朝一日继承您的应用程序将感谢您使用既定的标准，而不是“自己动手”。另外，.NET框架支持使用，编写，创建和修改app.config文件 - 如果你使用自己的方案，你将不得不多次重新发明轮子。
所以我肯定会推荐使用app.config - 这是THE在.NET中进行配置的方式，并且这是一个广为接受和支持良好的标准。
Marc
简单性和程序可读性。
App.config是.NET中用于存储配置的常规方法，因此其他程序员可能会看到它。它存储在XML中，因此与XML配置文件相比不会有任何性能。
它还可以处理的地方保存的app.config（的Documents and Settings/用户名 /本地设置/应用程序数据/ 您的应用程序 /）位置，并自动保存根据您的应用程序的位置和版本的配置，允许同一应用程序的多个版本共存。
我想说，不需要两个app.config和一个自定义XML文件，所以将两者结合起来可能是一个好主意。
恕我直言的应用程序。配置是不存储配置数据的一个非常方便的方式，主要是为那些有两个原因：
我更喜欢使用我自己的配置类，我使用XML序列化来加载和保存。您仍然可以从强类型设置中获益，而且它更加灵活，因为您可以定义任何需要的结构
如果项目的生命周期将其从一个环境移动到另一个环境，将它分割成不同的文件非常有用。
例如，当开发人员在处理代码时，您可能希望应用程序指向“devsql”框。当是时候进行QA'd，代码被部署到登台服务器，并且你希望应用程序指向'stagingsql'。
如果您保留了app.config中的所有配置，并且已对app.config的dev版本进行了设置更改，则会将其复制并截断暂存版本 - 现在您的QA人员正指向开发数据库。
通过将'database.xml'与'app.config'分开，您可以允许不同环境之间的差异，但仍然允许更改配置文件从每个环境流向下一个环境，而不必担心覆盖定制。
我同意将XML序列化程序与“设置”类相结合是存储设置的绝佳位置，尤其是在您有很多自定义类型或对象的情况下。
在Web.config中创建类来定义自己的配置部分非常简单，它将为您提供对配置数据的强类型访问，允许您为配置信息定义一种模式等。请参阅，例如，this article [4guysfromrolla.com]获取实施细节。
App.config对连接和日志记录配置有很好的支持，您几乎可以在所有应用程序中使用它们。重写它们可能会带来很多工作。另外，如果在app.config中使用“sectionGroup”，则可以具有某种结构灵活性。
但是在做某件事之前，我会询问创建自定义配置文件的人为什么要这样做。有一些不寻常的情况，app.config会给你带来一些麻烦，比如你想通过Assembly.Load加载另一个DLL（带有它自己的app.config）。在这种情况下，您需要将两个配置合并到一个app.config中，并祈祷它们不会使用相同的密钥进行任何配置。
在网络测试中，您无法覆盖web.config配置，因此也可能会带来一些麻烦，因此无法执行您想要的操作。
但恕我直言，它只是在不寻常的情况下，app.config不会很好地工作。在大多数情况下，我认为不值得创建自己的配置框架。
App.config是默认设置，在大多数情况下，它是处理应用程序配置的最佳方式，当您需要解析文件以获取值以及文件变得足够大时，这成为一个问题。
这对于具有大型网站的网络应用来说更是一个问题。配置文件，每次你提出请求时，web.config得到解析，这可能会导致税收，你会看到一些ORM mapers。
您还可以轻松加密app.config的各个部分。 – RichardOD 2009-06-25 20:30:48
优点，是的！ – 2009-06-25 20:31:39
@RichardOD如果你可以添加一个详细介绍如何进行加密的链接，这将是非常棒的。 – 2010-03-29 18:27:14