使用 ConfigSource 特性 拆分 Web.config 文件

一个大项目里可能会有非常多个配置参数，有.Net自己支持的配置（比如WCF，AppSettings），还有一部分是自定义的配置（比如继承自ConfigurationSection和ConfigurationElement的配置类），当然还有一部分是第三方类库的配置（其实也是自定义的配置，比如AOP框架Unity），当这些配置变得越来越多的时候，维护起来变得相当困难，特别是config文件内容相当的长和文件的容量过大，过大的文件在Config初始化读取文件时会带来性能影响，这个时候使用configSouce指定外部的文件，拆分成多个不同的文件存储配置，增强可读性和可维护性，降低出错的风险。

MSDN里提到了3点好处：

Using include files can result in a more logical and modular structure for configuration files. （模块化管理文件）

File-access security and permissions can be used to restrict access to sections of configuration settings. （可控制不同配置文件的访问权限）

Settings in an include file that are not used during application initialization can be modified and reloaded without requiring an application restart. （修改不在应用程序初始化时候使用的参数，不需要重启应用）

很多文章里都也已经说了关于ConfigSouce的用法，根据MSDN说明，ConfigSouce只能用于ConfigurationSection对应的节点，比如

<appSettings configSource="Config\\AppSettings\\appSettings.config"></appSettings>

在appSettings.config里

<appSettings>  <add key="IOS" value=""/>  <add key="Android" value=""/></appSettings>

这里appSettings是定义在machine.config里configSection，这样.Net会自动找到对应文件。

对于appSettings，在Web.config里IDE会给你智能提示，告诉你它支持configSouce属性，但是有些不会，比如配置WCF服务的system.serviceModel/services节点，这种节点也是支持的，因为从machine.config里会看到，services也是一个ConfigurationSection

Capture

所以如下配置是正确的：

<services configSource="Config\\ServiceModel\\Services.config"> </services>

对于自定义的配置，或者第三方类库配置，因为都是继承了ConfigurationSection

Capture

所以如下配置也是正确的：

自定义的邮件相关配置

<VRentEmail configSource="Config\\VRentEmail\\VRentEmail.config"></VRentEmail>

Unity的配置

<unity configSource="Config\\Unity\\Unity.config"> </unity>

使用了configSource后有一个明显的缺点就是，智能感知没有了