需要一种方法来控制 app.config 文件

Question

目前我们有 4 个人正在研究解决方案。该解决方案由一个中央可执行项目（Windows 服务）和许多类库解决方案组成。 Windows 服务有一个 app.config 文件，但由于某种原因，它的“复制到输出目录”设置被设置为“不复制”，因此我们可以在本次讨论中忽略它。

有两个不同的类库项目具有 app.config 文件。在其中一个项目中，它被复制到 bin\Debug 文件夹中作为 MyClassLibrary.dll.config，而另一个 DLL 的 bin\Debug 文件夹中同时包含 MyOtherClassLibrary.dll.config 和 app.config。我不知道这是怎么发生的。

这些是解决方案中的所有 app.config 文件。

解决方案中有一个MSTest项目。它有几个带有 [TestClass] 属性的类，每个类都在自己的 .cs 文件中。当我查看该项目的 bin\Debug 文件夹时，我在其中找到了 MyClassLibrary.dll 和 App.config，但没有 MyOtherClassLibrary.dll。这很奇怪，但这就是我所看到的。

如您所知，当我去运行其中一项测试时，文件将被复制到解决方案的 TestResults 文件夹中的特殊测试文件夹中。当我查看该文件夹时，我只找到一个 MyTestProject.dll.config 文件。当我打开它时，它的内容是 app.config 文件的内容。

这是怎么回事？我认为 Visual Studio 将所有配置文件合并在一起？ MyClassLibrary.dll.config 文件中缺少设置（显然）会破坏依赖它的代码。

我们该如何解决这个问题？

托尼

编辑：

我刚刚仔细检查了 MyClassLibrary bin\Debug 文件夹 &同时具有 app.config 和MyClassLibrary.dll.config，所以我想我在 MyOtherClassLibrary 中看到的内容是正常的。我们只需要一种方法来管理所有这些设置。

Answer 1

不，VS 不会将配置文件合并在一起。它不会这样做，因为可能有一个解决方案可以生成两个或多个可执行文件作为项目。即使对于最终总是作为类库并且只有一个可执行文件的项目，由于关注点分离，合并 app.configs 也不是一个好主意；项目库应该是一个“黑匣子”，引用代码只需要通过实例化方法和调用方法的外部接口即可。根据定义，app.config 及其信息是一个实现细节，只有需要它的项目才应该知道，而不是引用它的项目。此外，如果您独立于另一个可执行文件重新编译项目库并推出新的 DLL，那么配置文件将如何合并？

如果一个项目有 app.config，则会专门为该项目创建一个配置，该配置与所有其他项目不同且独立。

如果您的配置在公共部分中具有公共数据，则可以通过为这些部分指定外部配置文件并使用“configSource”属性从每个项目的“主”配置文件引用它来最大程度地减少冗余数据量。

Answer 2

您应该只需要一个 配置文件，并且它可以是正在执行的项目（即控制台项目、Web 应用程序项目等）的一部分。如果类库之一中的类引用配置值，则它应该可以从执行项目中访问该配置值/作用域。我从来没有见过任何自动合并。

Answer 3

您将设置拉入主配置或实现一些在构建时合并某些设置的内容，我在这里以某种相关的方式谈到这一点：
Visual studio 2010 - 每个开发人员/计算机/环境 Web。配置设置 默认

情况下，您不会在主配置之外自动复制任何内容，它不会那样工作。

Answer 4

请记住，像这样的配置文件（包括 web.config 和 app.config 文件）会发生两件事：

1. 按原样部署文件。它可能会进行转换，但文件会按原样部署。

2. 它被编译为属于程序集。因此，我名为 ProjectOne 的项目将对其 App.Config 文件进行编译并重命名为 ProjectOne.dll.config（假设我的 ProjectOne 程序集是“ ProjectOne")

这很重要，因为它完全与范围有关。此重命名是设计使然，因为它仍然允许项目程序集首先访问其自己的配置文件。这些将优先于方案 1 中的实际 app.config。

您可以通过更改文件的属性来防止方案 2 发生，以便 MSBuild 不会触及该文件。然后它可能会尝试按原样部署它。在这种情况下，它将根据构建顺序覆盖任何先前部署的。