ost 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 applies only to the specific application for which it was created.
For the Data Protection Provider to be used by the CMAB, it must be supported and called by the Configuration Section Provider you are using.
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 environment-specific settings such as database connection strings in the configuration file, you have to deploy the file 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 Configuration Management Application Block is part of a series of best practice implementations that Microsoft has put together. You can read an article on the Data Access Application Block in the November/December 2004 issue of CoDe Magazine , and an article on the Exception Management Block in the November/December 2002 issue of CoDe Magazine. (These articles are available in the DevX Premier Club