如果我们研究了每个应用程序的集合，结果将如下：
\wwwroot\web.config
first = C98E4F32123A
second = DD0275C8EA1B
third = 629B59A001FC
\wwwroot\firstapp\web.config
first = FB54CD34AA92
second = DD0275C8EA1B
third = 629B59A001FC
fourth = DE67F90ACC3C
\wwwroot\anotherapp\web.config
first = C98E4F32123A
second = DD0275C8EA1B
third = 629B59A001FC
fourth = 123ABC456DEF
fifth = ABC123DEF456
sixth = 0F9E8D7C6B5A
\wwwroot\anotherapp\childapp\web.config
first = C98E4F32123A
third = 629B59A001FC
fifth = ABC123DEF456
seventh = ABC123DEF456
ninth = 0F9E8D7C6B5A
\wwwroot\lastapp\web.config
first = AABBCCDDEEFF
second = 112233445566
third = 778899000000
fourth = 0A0B0C0D0E0F
我希望这个简单的示例，子应用程序的web.config是如何继承设置的，这些设置是如何被覆写，足够了。你可能不是经常遇到这种情况，但是了解发生了什么，以及如何覆写父web.config的配置设置，应该有助于减轻ASP.NET开发者的配置文件问题。
12.2、附录B： 包含外部配置文件
尽管在.NET 2.0的配置功能中都很伟大，但是仍有一个缺点。当工作在一个多环境的单一项目中，管理配置文件是一个噩梦。管理多环境下的多版本的配置文件(如开发、测试、阶段、产品)的过程，我目前的工作包括手工比较.config文件，将更改部署到一个环境或另外一个，通过手工合并。我花了几个月试图找到一种更好的方法，最终找到了。进入这样那样一些没有“没有文档的”或很少文档的——微软著名的特点，的其中的一个：configSource。当我用Reflector深入挖掘.NET 2.0配置源码的时候，碰到这个珍品，美妙的小工具。
每个配置节在被.NET配置类解析和加载时，都分配了一个SectionInformation对象。SectionInformation对象包含关于配置节的元信息，并允许管理节如何互相覆写，当定义在一个子web.config中时(ASP.NET)。现在，我们将忽略大部分SectionInformation对象提供的，考虑configSource属性(property)。通过添加configSource属性(attribute)到任何ConfigurationSection的根元素，你可以指定一个备用，外部的配置设置将被加载。
