configurationHelper: Easy to use config-store
configurationHelper is the second utility class I will discuss, it provides a simple and flexible configuration system that do not require you to predefine configuration entities in a schema.
Location of config-file
The configuration information is stored as key-value pairs in an XML file. The file is stored on disk and the location of the file is stored in the Registry, when the configuration information is first accessed it is read from disk and cached as a static field.
For each customer where I implement this I customize the Registry key to match the company name, hence I have used Contoso in the example below. The filename is stored in the default value for the key HKLM\Software\Contoso\Configuration, and it is a complete path and filename.
Access configuration values
All access to configuration information is done using calls to a static property, so there is no need to create instances of the class. Here is a typical example of accessing config information: string level = configurationHelper.AppSettings["traceHelper.TraceLevel"];
All configuration values are strings, so if you wish to store integers or boolean values you will have to convert them to their proper type. Typically this can be done using Convert.ToInt32(configValue).
Format of config-file
As mentioned above the configuration information is in the form of key-value pairs. All keys that are inserted will automatically be available to users, there is no need to register a config key in a schema or anything like that. An example of a config-file is:
<configuration>
<appSettings>
<!--
This section contains configuration realted to tracing.
To disable trace completely set traceHelper.TraceEnabled to false.
-->
<appSetting name="traceHelper.TraceEnabled" value="true" />
<appSetting name="traceHelper.TraceLevel" value="5" />
</appSettings>
</configuration>
Reloading values when config-file is updated
Even though the configuration information is cached it is very dynamic. During initialization it creates a FileSystemWatcher which monitors changes to the config-file, and if it is updated the contents is reloaded. This means that if you change, add or remove a value it will immediately take affect. At least this works for windows applications and web applications, but when I used it in a BizTalk (2004) project it did not reload when the file was changed. I have no explanation for this behavior (perhaps it’s related to security/privileges) but now you know that there might be a problem…
Pros and cons
I find the biggest advantage of this class to be its flexibility and ability to be used in many different types of applications. When a developer needs a new configuration value he simply adds it to the config-file.
The flexibility may also be a disadvantage when working in a multi-developer multi-server environment. When a developer adds a new configuration value it might affect all developers and if the application is in production the change has to be migrated to multiple servers.
You can also consider access to config-info a security issues, especially if you keep username and/or passwords in clear-text. You can always use ACLs on the config-file, but the real solution is to NEVER store sensitive information unecrypted regardless if the storage is a file or a database.
Having a central storage of configuration information would make it simpler in some cases. If you consider central storage a requirement then you should look at the Enterprise Library, it’s more complex but also allows for less flexibility.