Configure It Out with the Configuration Management Application Block

Managing application configuration and meta-data could not get any easier. Every application needs some way to configure itself so that it may interact with a given environment, whether it is customizing the title bar captions for a specific client or setting database connection strings for a development environment. For the simplest of applications, the app.config or machine.config probably meets your needs. For complex applications where security, scalability, and deployment also have to be addressed, you may need something a bit more robust, secure, and scalable. Enter the Configuration Management Application Block.

Most applications require some sort of configuration data, whether it is a file resource, a database connection string, user settings, a Web service URL, or simply organizational branding requirements. To address these issues prior to .NET, developers had to utilize some type of ASCII file such as an ini file, or they could use the Windows registry. Today with .NET, application configuration data can be stored in a specialized XML file called a configuration file.

Every .NET application has two configuration files that it uses for its settings. One is called the machine.config file and the other is called the app.config file for Windows applications or a web.config file for Web applications. The machine.config file stores configuration data at the machine level, applying the configuration data to all applications running on that particular computer. The application configuration file stores configuration data at the application level and the configuration data only applies to the specific application for which it was created.

Using the .NET machine or application configuration files is an improvement from having to roll out your own mechanism for reading configuration data, but it has some drawbacks.

• The machine and application configuration files are read only, which makes storing configuration data in the .NET configuration files at run time impossible.
• When storing data in the configuration file, perhaps environment-specific settings such as database connection strings, the configuration file has to be deployed to all computers requiring the application. This can be an issue when an application is promoted from a development environment to production with new configuration data. It is possible to mistype new settings into the .NET configuration file.
• Security can be a critical issue in some environments. The configuration file is an XML document that can be read by anyone who has access to it. For Web applications, this is more difficult because ASP.NET prevents browsing the web.config file. However, with a Windows application configuration file, if a user has access to the executable, the user also has access to the configuration file.

To address these issues, you can always roll your own solution, but that can be time consuming, and you probably will have to do a lot of refactoring as your needs grow. The other way to solve these issues is to find some implementation on the Web and tweak it to meet your needs. Microsoft, through its practices and patterns group, has created just such an implementation, called the Configuration Management Application Block or CMAB for short, which addresses the above-mentioned concerns and more.

The Concept and Design of the CMAB

The CMAB addresses the needs of storing and retrieving application configuration data by creating a simple, consistent, extensible interface, including:

• A flexible data model, allowing storage of simple name-value pairs or complex hierarchal data such as an XML fragment of user preference data. This flexible representation of configuration data is handled by the Configuration Section Handler or CSH interface.
• An ability to write to any data store via the Configuration Storage Provider or CSP interface. This gives you the ability to store data as an XML file in a database of your choice, or anything else you can think of.
• A mechanism to handle security and data integrity. Storing data, such as a connection string in an XML file, can at times be less than ideal. The Data Protection Provider, or DPP interface, provides mechanisms for signing the stored configuration data and encrypting it, helping to ensure that your data is not viewed or edited by unauthorized eyes.
• An option to cache the data stored by any CSP. With some CSP implementations, it can also refresh the cache when the data changes.

The CMAB provides pre-built implementations of the Configuration Section Handler (CSH), Configuration Storage Provider (CSP), and Data Protection Provider (DPP). You can use these as is, tweak them to meet your specific needs, or create your own implementation from scratch.

By: Keenan Newton

Keenan is a Senior Consultant for Magenic Technologies, Inc., one of the nation's premiere Microsoft Gold Certified Partners, focused on delivering business value through applied technology. He has over eight years of experience designing, architecting, and developing n-tier applications for both Windows and Web environments.

knewton@calamos.com