A year and a half ago I wrote about my Application Configuration library that I use to handle all things related to configuration in most of my applications. The library is a code-first, class based configuration implementation where you simply create a class that inherits from a base type, add properties, and then use that class for configuration access and storage mechanism. The library provides auto-initialization and auto-creation of configuration stores. By default .NET .config files are used, but with a few lines of configuration switching providers you can easily configure providers to also use raw JSON and XML files, database records or string based storage.

This is a tool I use daily and in just about every application I built as a way to centrally store my configuration settings without having to think about how the configuration is stored. I create the class add properties as needed and the class provides the rest. Done.

In case you want to check out the project, here’s where to find more detailed info:

The latter link is a lengthy post that details the rationale behind this library as a getting started guide. The GitHub page also has similar getting started content in more direct no-nonsense fashion, but without the backstory.

When I wrote the post I had just updated the library to version 2.0, which revamped the whole implementation to make it much easier to set up from its original incarnation. I had also just moved the project out of the larger West Wind Web Toolkit into its own library and open sourced the whole shebang over to GitHub. There’s been some decent interest and feedback, and now with the version being up to 2.20 I thought it’s high time to highlight a few of the changes that were implemented since then.

Open Sourced – MIT Licensed

The original library was part of the West Wind Web Toolkit which was a (cheaply) licensed product and that caused some confusion as to the actual licensing of the library. As of mid-2013 the library is fully open source and available using the MIT license, which means you’re free to use it in just about any kind of project without any restrictions. There’s still an optional commercial license available for those that require physical licenses, feel that official personal support related to the license is required or those that simply want to support this project. Surprisingly since then quite a few people have decided to pay for a license – more so than prior to having the project under MIT. Hmmm… makes you think, huh?

Open Sourcing has been nice –there have been a few contributions and a few interesting additions in various forks. It definitely is a more interactive environment and has brought more people in to use and discuss the tool. Incidentally this was also my first public experience with Git and GitHub which has been awesome (how did I ever get along without it?)

JSON Configuration Support

A lot of people asked for JSON serialization support as an option, and originally I was somewhat resistant to it. My main reason for the resistance was primarily that it adds a dependency on a JSON parser and that that it is pretty easy to serialize to JSON manually – plus JSON as a configuration format can be troublesome because of string encoding issues. However, after getting so many requests for it I ended up adding support for it after all.

Dynamic JSON.NET

I ended creating a dynamic implementation of the JSON serialization code that uses the JSON.NET library, but doesn’t require a hard reference to JSON.NET. This means there’s no compile time dependency on JSON.NET and the NuGet package won’t explicitly pull down JSON .NET. So if you don’t use JSON serialization you don’t need to have JSON.NET in the project at runtime or even at compile time. If you want to use JSON, then just make sure JSON.NET is available by manually importing the NuGet package - or – much more likely it’ll already be part of your project anyway especially if it’s a Web project.

One thing that is nice with JSON (and also XML) is that it supports hierarchical structure, so it’s much nicer to build layer configuration objects that group related features together in child objects.Here’s an example of a JSON configuration class which I used in a recent desktop utility application I built:

Note that for desktop applications, you probably want to pick your configuration file storage path carefully – here I’m using Environment.SpecialFolder.ApplicationData, which translates to the AppData/Roaming folder that can both read and write data for the local user. Don’t put config files into the application’s main folder if you plan on also writing configuration information to disk.

Adding the configuration object to a global App object is an optional step, but I use that approach for just about every application – Web, desktop or otherwise. By adding one ore more Configuration objects as statics to a ‘global’ App object, the configuration becomes globally available in the application as a Singleton, at which point I can use the configuration like this from anywhere in the application:

As I mentioned this is also easy enough to do manually, by creating Load() and Save() methods that handle the serialization/deserialization, but I find that using configuration class provides a common pattern for holding these configuration values consistently and potentially allowing them to be stored in a different store if necessary.

Configuration File Support for Complex Objects

As you can see in the example above, it’s pretty nice to have complex objects that nest configuration values. Unfortunately, .NET’s .config file structure doesn’t lend itself to this model very easily as the dynamic system uses key value pairs that map well to single level classes, but not so much to hierarchical data.

However, it is possible to trick the standard key value pair format into supporting simple complex objects and lists and the latest version provides some of this support. There are two ways to make this happen:

Using custom ToString() and static FromString() methods to serialize and parse data

Using .NET TypeConverter Attributes

Support for the latter TypeConverters has been in the tooling for a long time, but it’s a bit of a pain to use. This release however adds support for object serialization/parsing by providing a static FromString() method to deserialize and a ToString() method to serialize complex object data.

Notice the static FromString() method which the .config file provider probes for if no default type can be matched. If the method exists ToString() is used to serialize and FromString() is used to create an instance of the type from a string. In the example, a helper StringSerializer class is used to handle the serialization and deserialization. This class basically iterates through all properties concatenates the values for serialization, and then pulls them back from a string when parsing. Obviously FromString() and ToString() can use whatever mechanism you chose, but StringSerializer is a quick and easy way to take an object and turn it into something simple that’s editable by hand if necessary.

This may look somewhat silly and I agree that this shouldn’t be your primary goal in configuration design. If you truly need nested objects, it’s better to use JSON or XML and persist that way, rather than using .config file formatting. However I’ve found that I’ve needed to use this feature quite a bit recently, especially in projects that have been around a while where configuration keys are growing in size and some order is needed to keep values organized. Sometimes there are related values that are easier to edit as a single string.

This feature is also useful for the next feature enhancement which is lists where you can have multiple list items represented as nested string values.

Configuration File support for IList

Another feature that creeps up from time to time is the ability to display multiple items of the same type – a list essentially. In a recent project we needed to configure multiple queue servers for startup with each server with its own three or four settings. The ConfigurationFileConfigurationProvider serializes and parses IList based values by iterating over each item and serializing it using the string parsing routines used for single elements. This means you can serialize both simple values like lists of strings, or complex values like the LicenseInformation type above as long as it supports either a TypeConverter or the FromString()/ToString() combination of methods.

Each item is serialized using the name of the property plus a one based index. Likewise the parser reads the list and checks for values starting with 1 and upwards until a value comes back null to retrieve the values.

It also works with complex values – here’s an example of a QueueConfiguration that has a list type that contains each queue configuration which holds the name of the queue, the number of processing threads and a wait interval:

Again this isn’t the cleanest design, but as is often the case when we started out we didn’t anticipate the need to have multiple queue configurations. This requirement came up much later when configuration settings and management through deployment targets had already been set and it was simply easier to shoehorn these queue settings into the existing .config file format we’d been using.

Both the complex type and IList support have proven very useful on a few occasions and although I don’t recommend them in your primary configuration layout, they can definitely be a life saver when you need to add settings that require more complexity in a hurry. If you have the option of re-design or starting from scratch and you find yourself adding complex objects or lists, then you’ll probably much happier with using a serialization format like JSON or XML that supports hierarchical layouts more naturally.

Summary

I’m glad to see this library is getting more use since it’s been rescued from relative obscurity in the West Wind West Wind Toolkit into it’s own more focused library. I’m starting to regret past decisions of building larger toolkits that included a hodgepodge of features – clearly it’s much better to have small but very focused tools that have appeal.

I hope this configuration class is useful to some of you as it has been to me.

The Voices of Reason

Hello I really love the Configuration Library. It's such a great tool!

I've got two questions. I'm using the SqlServerConfigurationProvider
#1. With support for Lists, how do I entrypt property in List objects? Is this possible?
#2. Is it possible to store the config data as JSON string in the database?

@Dirk - List encryption works only if you encrypt the entire list in the .config provider. IOW, the top level list property on the object. It'll encrypt/decrypt the encoded list string. There's no support for individual list values.

JSON storage in the database is not directly supported, but you can use the string provider to generate the JSON and store and retrieve that from the db manually. You can open an issue on Github and add it as a suggestion. Would be easy enough to add this functionality as another provider.

Can I use this to store my config in a separate file name in my class library that gets copied to the consumer of my library? I need to use something other than web.config or app.config because the consumers use those files.

What I want is myapp.config that I set the copy to bin property at compile time. Then my consumer knows nothing about my library configuration.

@Ryan - sure. The native .NET infrastructure actually supports .config files in non-standard names, but yes this class lets you use that as well. you can use either XML (same format as .NET config), or Json for the custom configuration files.

I have an ApplicationConfiguration class that extends Westwind.Utilities.Configuration.AppConfiguration, and the <ApplicationConfiguration> element is under <configuration>.

I did try adding a <configSections><section name="ApplicationConfiguration" type="Namespace.ApplicationConfiguration, MyAssembly" /></configSections> but that doesn't seem to make a difference. ("Namespace" and "MyAssembly" arent the actual namespace and assembly values for the purpose of this post)

The program is a console app, so the config is stored in App.config.

Have I made a bad assumption how this lib could be used to read structured config settings from an existing App.config?

@Reuben - not sure. If you use a Console app and you have rights to write the file in the folder, the configuration manager should write a new configuration section and all that's related to it for you.

Take a look at the tests and samples and compare if there's anything different. Without more info I can't really help.

I have similar issue as Reuben. In a web application, all sections and config values are automatically created. But with console app, nothing happened. If I manually create those sections, it can read. But new value is not auto added to app.config. It's an empty console app, just the package, a ApplicationConfiguration class and default initialize in main.

Not that it's a deal breaker, but the auto create value feature is too good and addictive ^_^