It's a requirement I've heard a few times: "Is it possible to break my web.config or app.config into multiple files?".
.NET 2.0 introduced the configSource attribute which allows you to specify a seperate file for each section:
<configuration>
<configSections>
<section
name="customConfig"
type="Examples.Configuration.CustomConfigHandler, Examples.Configuration" />
</configSections>
<customConfig configSource="customConfig.config" />
</configuration>
But if you have a lot of configuration sections, and many people do, this can result in far too many files.
Enterprise Library has a nice solution to this with it's introduction of the ConfigurationSource in EntLib2.
Tom Hollander explains it beautifully in this post
External configuration files in Enterprise Library for .NET Framework 2.0.
The basic idea is that you configure a ConfigurationSource in your app/web.config and this can then point to another file[
1] source. And the file can contain as many configuration sections as you like.
<configuration>
<configSections>
<section
name="enterpriseLibrary.ConfigurationSource"
type="Microsoft.Practices.EnterpriseLibrary. Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null" />
</configSections>
<enterpriseLibrary.ConfigurationSource
selectedSource="File Configuration Source">
<sources>
<add
name="File Configuration Source"
type="Microsoft.Practices.EnterpriseLibrary. Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null"
filePath="customConfig.config" />
</sources>
</enterpriseLibrary.ConfigurationSource>
</configuration>
Awesome. So now you can easily move all of your Enterprise Library configuration into a seperate file.
But what about my own custom configuration sections?
Well, that's pretty easy too. Here's a very simple configuration section handler built using .NET 2.0's configuration libraries:
public class CustomConfigHandler : ConfigurationSection
{
[ConfigurationProperty("someValue", DefaultValue=0, IsRequired=false)]
public int SomeValue
{
get
{
return (int)this["someValue"];
}
set
{
this["someValue"] = value;
}
}
}
Which would normally be configured into you app.config like so:
<configuration>
<configSections>
<section
name="customConfig"
type="TheJoyOfCode.Examples.EntLibConfigSourceDemo. CustomConfigHandler, TheJoyOfCode.Examples.EntLibConfigSourceDemo"/>
</configSections>
<customConfig someValue="070707" />
</configuration>
And then typically accessed something like this
CustomConfigHandler config = (CustomConfigHandler)ConfigurationManager.GetSection("customConfig");
Console.WriteLine(config.SomeValue);
But what if we wanted to move the customConfig section into another file (along with other sections) using Enterprise Library's ConfigurationSource. That's pretty easy too. First, move the entire contents of the above app.config into another file (say customConfig.config) and use the enterpriseLibrary.ConfigurationSource configuration above to point to the new file as a configuration source.
Now the main thing that needs to change is how we access configuration data programmatically.
IConfigurationSource source = ConfigurationSourceFactory.Create();
CustomConfigHandler config = (CustomConfigHandler)source.GetSection("customConfig");
Console.WriteLine(config.SomeValue);
And that's it. Nice.
Why not download the sample
console application and source code to have a proper look.
One little thing
The file path you specify in the source is relative, so you need to make sure a copy of the customConfig.config makes his way to the output folder (not such a problem for web applications) but for the
sample console application I had to set the files Copy To Output property to Copy Always in the file's properties.

[1] Enterprise Library 2 also ships with a SqlConfigurationSource to allow you to read the config from SQL. I haven't tried this yet but it could be useful if you have a lot of servers (or maybe even clients?) with the same config.
*Caution*: I have no idea if any of this stuff plays well with web applications in that, when a file changes the AppDomain is drain-stopped to reload the new config. I'll leave that as an exercise for the reader.

Post By
Josh Twist
7:17 AM
30 Mar 2007
» Next Post:
Good news for MSDN subscribers
« Previous Post:
Unit testing a logging wrapper
Comments are closed for this post.
Posted by
Brian
@
31 Mar 2007
6:39 PM
With the vanilla use of external config source you can specify restartOnExternalChanges="false" to prevent the application from stopping and restarting.
I don't know how EL treats this; I would hope the same.