使用 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

所以如下配置是正确的：

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

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

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

自定义的邮件相关配置

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

Unity的配置

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

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