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