Click here to Skip to main content
12,549,230 members (43,891 online)
Click here to Skip to main content
Add your own
alternative version


10 bookmarked

Intro to Qonfig - A simple config framework for C#

, 8 Nov 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
A simple and extensible configuration framework for .net4


Configuration. It's difficult to have a simple, application-wide solution thats available through different projects within your apps context.

I've been looking for a solution that's:

  • Extremely lightweight
  • Initialize once, use throughout the whole application
  • Very simple and easy to use
  • Extendable (Registry storage, .ini, ..)
  • Specific or dynamic names

The result is the Qonfig framework. Currently only registry is supported as storage, but other targets may follow soon. Anyways, you can extend it whenever you want.


Let's take a look at how easy it could possibly get to create a configuration context for your application.


public enum ConfigOption
    [ConfigurationOption("App:Style", "nice-style")]
class Program
    public void Main()
        Configurator.Init<ConfigOption>("Company:Product", typeof(RegistryAdapter));

So, whats going on here? First, we define the configuration model. Take a look at the ConfigOption enum. It contains an option, decorated with a special attribute that defines the path and name (use ':', '/' or '\' for separation) and the default value.

Then, we execute the Main function. First thing is to initialize the static Configurator class. As we want to use specific configuration options, we pass the ConfigOption enum type as <T> and the configuration storage path (again, choose the separator) as a string. Optionally, set the adapter type or get the default one (RegistryAdapter).

This will create an entry to your registry, under "LocalMachine or CurrentUser\Software\Company\Product\App" named "Style" with an empty value.

Why the value is empty you ask? The answer is, why store it, if it's default anyways? This way, if you decide to change the default value, the old default value is safely ignored on machines that have executed your old code before. Why create it you ask? For the sake of letting them users know, what options there is to set! 

Wether to use LocalMachine or CurrentUser is left to be decided by the app, depending on the privileges it has. A behavior that may be customized by setting forceLocalStorage in the constructor to be true:

Configurator.Init<ConfigOption>("Company:Product", typeof(RegistryAdapter), true); 

Next, use the enum extensions GetConfigurationValue<T> and SetConfigurationValue to get the value of a specific type or to set it. 

Thats it for explicit usage of the library. So lets get on with dynamic usage!


class Program
    public void Main()
        Configurator.Library.Add("App:Style", "nice-style");
        Configurator.Set("App:Style", "nicer-style");

Ok, initialize the Configurator with a storage path and dynamically add as much configuration items to the Library as you wish. Define the path and name as well as a default value, if you wish.


What if you don't want those default values? You wished you could just add options without specifying any value? Easy, just set the attributes' typeof or dynamically add the option without anything specified but the path/name.

public enum ConfigOption
    [ConfigurationOption("Application:Style", typeof(string))]


You'd like to use configuration options that shall not be modified by any user? Go on, define the NonPersistent property and assign it the 'true' value! Or add the option using the Library.AddNonPersistent method if you're on the dynamic side.

public enum ConfigOption
    [ConfigurationOption("Application:Style", typeof(string), NonPersistent = true)]
Configurator.Library.AddNonPersistent("App:Style", "nice-style");    

And thats it, nice and easy persistency control!


Choices are always good, so how do I store my data? Just specify an adapter or go and write your own (just implement the abstract ConfigurationAdapter class and you're set)! 

Configurator.Init<ConfigOption>("Company:Product", typeof(RegistryAdapter)); 

As said, you can force the local storage to be used by specifying 'true' within the constructor. Imagine the LocalAppData to always be used (File-Storage) or the CurrentUser in the registry.

Well.. this is it for the first part. I will try to create a more detailed look behind the scenes as soon as possible. Until then, just take a look at the source code! It's been completely and carefully commented.

Next, I'll try and add file storage and multiple target support with priorities. 

Leave me a comment, will ya?

Source-Code is hosted on bitbucket, as the upload function on CodeProject returned "Unexpected error during upload" constantly. Maybe we will get to fix that soon.  


  • Revision 1 (initial), 2013-11-7


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

No Biography provided

You may also be interested in...


Comments and Discussions

GeneralMy vote of 5 Pin
fredatcodeproject8-Nov-13 5:58
memberfredatcodeproject8-Nov-13 5:58 
GeneralRe: My vote of 5 Pin
Benjamin Kniffler8-Nov-13 6:03
memberBenjamin Kniffler8-Nov-13 6:03 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.161021.1 | Last Updated 8 Nov 2013
Article Copyright 2013 by Benjamin Kniffler
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid