多重环境下web.config配置管理解决方案

多重环境下web.config配置管理解决方案2010-12-15Figo面临的问题

在大型web应用开发中，为了保证应用的质量，保证用户体验，我们开发时总要经历从开发，测试，beta到最终上线的过程。

因为不同的测试运行环境的参数都不同，所以在实际开发中我们可以编写多个web.config，每个web.config特定用于某个测试运行环境。这一切看上去似乎顺理成章，但随着你的应用越做越大，web.config也会越来越大，而麻烦也会随之而来。

复杂的web.config是很难进行维护的，而且牵一发动全身。比如你开发时有一个配置节要进行修改，那所有环境下的web.config对应的节也都要做相应的修改。特别是在web.config很大，各种测试环境又多的情况下，SCM管理员肯定会抓狂的……

化整为零

幸运的是，从.net 2.0开始，微软提供了configSource属性来让我们可以对web.config进行拆分。让我们来看个简单的例子：

[Web.config]
...
<system.web>
...
<profile configSource="profile.config" />
...
</system.web>
...
[profile.config]
<profile>
<properties>
<add name="Name" type="String" />
<add name="Age" type="Int32" />
</properties>
</profile>

在上面的例子中，我们对<system.web/profile>配置节进行了拆分，此配置节的具体配置是存储在另一个单独文件profile.config中，而web.config只需要通过 configSource这个属性来指明配置节的具体配置存储在哪个文件中，web.config 就会在运行时自动去寻找到那个文件并加载。

在进行拆分时，我们需要注意以下几点：

只允许针对配置节（ConfigurationSection）进行拆分，而不能对配置节组（ConfigurationSectionGroup）或元素（Element）进行拆分。

存储配置节内容的文件的后缀名需要小心，理论上文件名可以任意取，web.config都能读取。但出于安全的考虑，我们的后缀名最好是不能直接通过url访问的文件类型，以防止泄漏配置信息。所以.config是可以考虑的，.xml,.txt等后缀极力不推荐。

默认情况下，如果特定配置节的 config文件内容更改，iis是察觉不到的，所以不会重启程序池。假如你需要在特定配置节config文件修改后能让iis自动察觉到并进行重启，可以利用 RestartOnExternalChanges属性，具体参见MSDN。