Configuration is a breeze.
In the current Visual Studio .NET 2005, you’re going to find that a great thing has happened to configuration. Basically, the mechanism for creating, editing, and parsing configuration sections just got really easy. If this particular item snags a bit of interest, I’ll go as deep as I can in future posts. Here is a teaser to see if there is any real interest.
Let’s say that I have a reason for configuration. The data I need to store happens to be the following:
- A string
- An integer
- A TimeSpan (for timeouts?)
Let’s say that I want the serialized format to look like this:
<mySpecialSection someString=”value” someInteger=”9” timeout=”00:12:30”/>
Previously, I would have to write a bunch of code that parsed an XML stream and sorted the data into the right data members. Today, the code to read and write the above looks like this:
using System;
using System.Configuration;
using System.Reflection;
public class MySpecialSection : ConfigurationSection
{
[ConfigurationProperty(MySpecialSection.configSomeString,
DefaultValue = "default")]
public string SomeString
{
get { return (string)base[MySpecialSection.configSomeString]; }
set { base[MySpecialSection.configSomeString] = value; }
}
[ConfigurationProperty(MySpecialSection.configSomeInteger,
DefaultValue = 1)]
public int SomeInteger
{
get { return (int)base[MySpecialSection.configSomeInteger]; }
set { base[MySpecialSection.configSomeInteger] = value; }
}
[ConfigurationProperty(MySpecialSection.configTimeout)]
public TimeSpan Timeout
{
get { return (TimeSpan)base[MySpecialSection.configTimeout]; }
set { base[MySpecialSection.configTimeout] = value; }
}
const string configSomeString = "someString";
const string configSomeInteger = "someInteger";
const string configTimeout = "timeout";
}
Then, to write out the configuration AND make sure that this section was included in the right configuration file, you would have this:
public class App
{
static public void Main(string[] args)
{
Configuration config = Configuration.GetExeConfiguration(
Assembly.GetExecutingAssembly().Location,
ConfigurationUserLevel.None);
//Load my section from config
MySpecialSection section = config.Sections["mySpecialSection"]
as MySpecialSection;
if (section == null)
{
// The section wasn't found, so add it.
section = new MySpecialSection();
section.RequireDeclaration(true);
config.Sections.Add("mySpecialSection", section);
}
section.Timeout = TimeSpan.FromMinutes(4);
section.SomeInteger = 15;
section.SomeString = "Hello!";
// Save the changes.
config.Update();
}
}
The output of the above is:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="mySpecialSection" type="MySpecialSection, Test, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" />
</configSections>
<mySpecialSection someString="Hello!" someInteger="15"
timeout="00:04:00" />
</configuration>
Not bad! I don’t know how you are configuring your applications today, but this particular model is nice. This particular OM has a few other benefits as well. For example, calls to ConfigurationSettings.GetConfig always succeed for configuration sections that are implemented by a ConfigurationSection-derived class. No more checking for null and filling in your defaults from some other area. Instead, you set the default values in your ConfigurationSection.
Why have the default values in the ConfigurationSection? Doing so provides the following benefits:
- If the user is happy with the default value, this is what you read back.
- If the user sets the setting to the default value, the configuration system writes out nothing. It’s also faster to read back the default setting since it takes zero time to read nothing.
I’ve been using this framework to develop a lot of configuration code for Indigo, System.Net, and System.Transactions. If you have stayed away from config up until now, give this stuff another look. You’ll be pretty happy!
By the way, at runtime when your application is reading the settings you would still load the settings using ConfigurationSettings.GetConfig(”mySpecialSection”).
