我目前正在完成由其他人启动的应用程序。他正在使用app.config进行某些设置，并使用自定义xml文件进行其他部分。这让我疯狂，我想将配置合并到一个文件中。
但是我不确定是否将所有内容移到app.config中并抛出自定义xml文件，或将所有内容移到另一个文件中并忘记app.config。
我可以看到两个参数，每个选项一个：
但我确信现在还有很多事情比我想象的要多。这就是我要问的原因：
使用app.config存储配置与“传统”配置文件有什么优缺点？
答案 0 :(得分：29)
使用app.config的主要好处是它是.NET应用程序存储其配置的默认支持方式。任何人使用该应用程序或有一天从您继承它将感谢您使用既定标准而不是“滚动自己”。
此外，.NET框架支持使用，编写，创建，修改app.config文件 - 如果您使用自己的方案，则必须多次重新发明轮子。
所以我肯定会建议使用app.config - 这是 在.NET中进行配置的方式，也是一种广泛接受且支持良好的标准。
马克
答案 1 :(得分：8)
如果项目的生命周期使其从一个环境移动到另一个环境，则将配置拆分为不同的文件非常有用。
例如，当开发人员正在处理代码时，您可能希望应用程序指向“devsql”框。当需要进行QA时，代码会被部署到临时服务器，并且您希望应用程序指向'stagingsql'。
如果您将所有配置保留在app.config中，并且已对app.config的开发版本进行了设置更改，则会将其复制并破坏暂存版本 - 现在您的QA人员指向开发数据库。
通过将'database.xml'与'app.config'分开，您可以允许各种环境之间的差异，但仍然允许更改配置文件从每个环境流向下一个环境，而不必担心覆盖自定义。
答案 2 :(得分：5)
IMHO app.config不是一种存储配置数据的非常方便的方式，主要是出于以下两个原因：
我更喜欢使用自己的配置类，我使用XML序列化加载和保存。您仍然可以获得强类型设置的好处，并且它更加灵活，因为您可以定义任何您想要的结构
答案 3 :(得分：2)
App.config对连接和日志记录配置有很好的支持，您将在几乎所有应用程序中使用它们。重写它们可能会带给你很多工作。此外，如果在app.config上使用“sectionGroup”，则可以具有一定的结构灵活性。
但在做某事之前，我会问创建自定义配置文件的人为什么这样做。有一些不寻常的情况，app.config会给你带来一些麻烦，比如你想通过Assembly.Load加载另一个DLL（有自己的app.config）。在这种情况下，您需要在一个app.config中合并这两个配置，并祈祷他们不会使用相同的密钥进行任何配置。
在网络测试中，你不能覆盖web.config配置，所以它也会带来一些麻烦，取决于你想做什么。
但恕我直言，只有在不寻常的情况下才能使app.config无法正常运行。在大多数常见情况下，我认为不值得创建自己的配置框架。
答案 4 :(得分：1)
简单性和程序可读性。
App.config是.NET中用于存储配置的常规方法，因此很可能其他程序员也会看到它。它以XML格式存储，因此与XML配置文件相比不会有任何性能。
它还处理保存app.config（Documents and Settings / 用户名 /本地设置/应用程序数据/ 您的应用程序 /）的位置并自动保存配置根据应用程序的位置和版本，允许同一应用程序的多个版本共存。
我认为不需要同时使用app.config和自定义XML文件，因此将两者结合起来可能是一个好主意。
答案 5 :(得分：1)
我同意XML序列化程序与“设置”类相结合是存储设置的绝佳位置，尤其是当您有大量自定义类型或对象时。
答案 6 :(得分：1)
创建类以在Web.config中定义自己的配置部分非常容易，这将为您提供对配置数据的强类型访问，允许您为配置信息定义一种模式，等等。实例，this article [4guysfromrolla.com]了解实施细节。
答案 7 :(得分：1)
App.config是默认设置，在大多数情况下是处理应用程序配置的最佳方式，他们说当你需要解析文件以获取值并且文件变得足够大时会有成本成为一个问题。
对于具有大型web.config文件的Web应用程序来说，这是一个更大的问题，每次您发出请求解析web.config时都会产生这种问题，这会让一些ORM mapers看到这种情况。