Enterprise Library : Configuration Part 1.1.3 - ConfigurationContext

  • Article

Last week I did a podcast (why do we call it that when we use the WMA format?) with Ron Jacobs on the ConfigurationContext.  I know that the talk was abstract and probably a little hard to follow and I hope to clear that up today with another explanation and samples.

I want to start off by saying that we intentionally did not document this “feature” because: a) we ran out of time  , b) we knew it was  a hard concept to cover, and c) I didn’t think people would be that interested (see what you get when you assume things).

What is the ConfigurationContext ?
Glad you asked.  The ConfigurationContext is where your configuration data lives when it is loaded from storage and is the interface for read and writing this configuration data. It also serves as the interface for reading and writing the meta-data configuration. It has an internal cache and builds your data based on the defined meta-data (if you want to see this, look at the ConfigurationBuilder class).  Some of you that are familiar with the Configuration Library are probably scratching your head and thinking “wait a minute, I thought that is what the ConfigurationManager was for…”.  Well, you would be right.  Think of the ConfigurationManager as a ConfigurationContext that uses the app.config / web.config file for it’s meta-data storage.  You can use the ConfigurationManager for “most” of your ordinary needs, but the ConfigurationContext exists so when you have to do something that is extra-ordinary (80/20 rule) .  The ConfigurationContext allows you bypass normal operations and take full control.  I do want to warn you that by doing this, you are taking on a greater responsibility.. but relax, it is not that hard.

The Setup
There are a couple of main scenarios that the ConfigurationContext supports: 1) using a different file (not app.config / web.config) for reading/writing meta-data configuration; 2) allows you to use configuration that does not need any type of backing store and can be created dynamically within your application.

Most people don’t have a problem using their app.config or web.config for storing there meta-data configuration.  An example where this could be a pain point is when you are using COM+ on a Windows 2K box and you don’t want to store you configuration in the dllhost.exe.config file.  You don’t have to do that anymore.  You can create your own ConfigurationContext based on a different file.  The file has to follow the same schema as the app.config / web.config file, but other than that you are free. The following is an example of how you would create a ConfigurationContext based on a file:

    1:  ConfigurationContext context = ConfigurationManager.CreateContext(@"c:\myconfig.config");
   2:  // do something cool with the context, it contains all the meta data from the file

Another thing you might want to do is not have any configuration defined and completely define it in your application based on data gathered from other systems. The ConfigurationContext helps you do this as well. There are a few ways to approach this problem. I will try and describe each of them followed by a small example.

  • The first way to do this is using the ConfigurationDictionary object.  The ConfigurationDictionary is just a collection of name value pairs that are the section names and configuration settings objects.  You load up the ConfigurationDictionary with your settings and then create a ConfigurationContext based on these settings. Internally we just add these values to the cache and use these settings when you request a section of configuration. 
  • Another way to do this is having a little bit of knowledge that since we cache everything for you, knowing that, you can change the cached values under the covers and know that since everything is a reference in .NET, you will get the changed values every time that you request them.

See this post for examples on how this works.

How does this work with the other Blocks in the Library?
Here is where the fun begins.  Because you are taking a little more control of the situation yourself, you have to bypass the facades we put on top of the blocks.  Now that you have a context you can tell the block “hey, I want you to use this set of Configuration.”. 

Each block has a factory class that accepts a ConfigurationContext in it’s constructor. So instead of working with the DatabaseFactory you will use the DatabaseProviderFactory (sneaky huh) to create your Database.  This is exactly what the DatabaseFactory class does for you, but assumes you want to use the default ConfigurationContext.  Here is an example: 

    1:  // create a specific context
   2:  ConfigurationContext context = ConfigurationManager.CreateContext(@"c:\myconfig.config");
   3:  
   4:  // create the factory with the right context
   5:  DatabaseProviderFactory factory = new DatabaseProviderFactory(context);
   6:   
   7:  // create the named instance of the database
   8:  Database db = factory.Create("SalesDB");
   9:   
  10:  // get some data from the sales database

Now I admit, what would have been better is for us to add a member to the DatabaseFactory class to do this work for you accepting the context. Hindsight is 20/20 .  Of course, since you have the source, you could do this as well.

As Forest Gump would say, “Thats all I got to say about that.” (I am from Birmingham, AL not Greenbo ).  I hope this clears up the podcast I had with Ron.  If you have any questions please ask.  The best place is at the message board on the workspace so everyone can benefit from the answers.

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.

Now playing: 311 - Omaha Stylee