是的，您可以使用configSource配置块的属性。所有配置块均具有此属性-尽管未记录。

参见本文，始终在附录B的底部。我还粘贴了以下相关部分：

附录B：包括外部配置文件

尽管.NET
2.0的配置功能非常强大，但还是有一个缺点。在跨多个环境处理单个项目时，管理配置可能会成为噩梦。在我目前的工作中，为多个环境管理配置文件的多个版本（即开发，测试，分段和生产）的过程涉及到.config每当将更改部署到一个或另一个环境时，通过手动合并过程对文件进行手动比较。我花了几个月的时间试图找到一种更好的方法，最终找到了一种方法。输入其中一个如此受人喜爱的“未记录”功能-
在这种情况下，就是记录不充分的功能-微软非常有名的功能：configSource。当我使用出色的小工具Reflector挖掘.NET
2.0配置源代码时，才碰到这个小东西。

.NET配置类在解析和加载每个配置节时，都会为其分配一个SectionInformation对象。该SectionInformation对象包含有关配置节的元信息，并允许对子配置文件（ASP.NET）中定义的节之间如何相互覆盖进行一些管理。现在，我们将忽略SectionInformation提供的大部分内容，并保存该ConfigSource属性。通过将configSource属性添加到any的根元素ConfigurationSection，您可以指定一个备用外部源，将从中加载配置设置。

<!-- SomeProgram.exe.config -->
<configuration>
  <connectionStrings

configSource=”externalConfig/connectionStrings.config”/>

<!-- externalConfig/connectionStrings.config -->
<connectionStrings>
  <add name="conn" connectionString="blahblah" />
</connectionStrings>

在上面的配置文件中，该<connectionStrings>部分来自名为的文件externalConfig/connectionStrings.config。所有应用程序的连接字符串将从指定的文件中加载。现在，连接字符串是从外部资源加载的，connectionStrings.config在每个环境中的相同相对位置创建文件是相对简单的事情。因此，externalConfig/部分connectionStrings.config路径。这样做的好处是我们可以为每个环境正确定义一次连接字符串。我们不必担心在配置文件合并不当或根本不合并的部署过程中意外覆盖这些设置。当将应用程序中的更改部署到生产环境时，这是一个巨大的福音，在该环境中，正确的数据库连接字符串存在至关重要。使用该configSource属性的缺点是它要求将所有配置设置都放置在外部文件中。不能进行继承或覆盖，这在某些情况下使其无用。与该configSource属性一起使用的所有外部配置文件也必须驻留在main的相对子路径中.config文件。我认为这是出于安全考虑，将文件存储在Web环境中的相对父路径中。

还有一点要注意的是，本<appSettings>节可以使用configSource称为file
的更好的替代方法。如果您在本<appSettings>节中使用file属性而不是configSource，则可以在根.config文件和引用文件中定义设置。根.config文件中的设置也可以在引用的文件中被覆盖，只需添加具有相同密钥的内容即可。可悲的是，file属性仅在该<appSettings>部分可用，而未内置在配置框架中。您可以在自己的配置部分中实现类似的属性。在数个前提条件之后；这将在以后的高级配置主题中讨论；）。