Using Application Configuration Files in .NET, Page 2
Customized Configuration Sections and Groups
The issue with custom configuration sections alone is that they rely on attributes to store all of the settings as a part of a single element. This can become cumbersome when a large number of configurations are contained within a section or additional related sections. You can further organize similar custom sections into a section group, which makes it easier to work with numerous configurations and helps eliminate naming conflicts with custom configuration sections. This is especially useful where your application contains reference to several other DLLs that read configuration information from the host applications configuration file. A sectionGroup element is simply placed around one or more section elements to create a group. Expanding the example configuration file, the following configuration file contains a custom group, section, and the pre-defined appSettings:
<?xml version="1.0" encoding="utf-8" ?><configuration> <configSections> <section name="sampleSection" type="System.Configuration.SingleTagSectionHandler" /> <sectionGroup name="CodeGuru"> <section name="utilitySection" type="System.Configuration.NameValueSectionHandler, System,Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> </sectionGroup> </configSections> <sampleSection ApplicationTitle="Sample Console Application" ConnectionString="Server=localhost;Database=Northwind; Integrated Security=false;User Id=sa; Password=;" /> <CodeGuru> <utilitySection> <add key="ApplicationTitle" value="Sample Console Application" /> <add key="ConnectionString" value="Server=localhost;Database=Northwind; Integrated Security=false;User Id=sa; Password=;" /> </utilitySection> </CodeGuru> <appSettings> <add key="ApplicationTitle" value="Sample Console Application" /> <add key="ConnectionString" value="Server=localhost;Database=Northwind; Integrated Security=false;User Id=sa;Password=;" /> </appSettings></configuration>
Note the extra "Version," "Culture," and "PublicKeyToken" specified in defining a section group. These all come from what the machine.config configures on the local machine. Occasionally, it has worked for me without them, but other times an exception is thrown that it can't create the appropriate handler. I've found that if I include those items, it consistently works.
The following code can access the items in the custom group by loading the group into a NameValueCollection for easy access to the key and value pairs:
// Read custom sectionGroupNameValueCollection collection = (NameValueCollection) ConfigurationSettings.GetConfig("CodeGuru/utilitySection");string title = collection["ApplicationTitle"];string connectString = collection["ConnectionString"];
Note the path-like statement required to find the appropriate section to read when accessing the custom section.
This article has touched on some of the basics of using application configuration files, including the ability to define your own sections and groups of sections. Here are a couple of additional items for you to ponder about application configuration settings:
- Introduce some form of encryption to keep configuration settings safe. While the application configuration files are secured by operating system permissions, that won't always prevent prying eyes from seeing the information they contain. The use of plain text-based XML makes it insecure to store items such as connection string information that contain passwords within the configuration file. Building your own wrapper around the System.Configuration or creating a custom configuration section and implementing the IConfigurationSectionHandler interface in a custom handler allows you to build your own methods to include encryption to keep information secure in the application configuration file.
- Use application configuration settings to dynamically assign field and/or property values. This won't work for standalone DLLs that don't have a configuration file, but it will work if your DLL is utilized by an executable or ASP.NET application, as is often the case with utility libraries or business logic components.
The topic of the next column is yet to be determined. If you have something in particular that you would like me to explain, e-mail me at firstname.lastname@example.org.
About the Author
Mark Strawmyer, MCSD, MCSE, MCDBA is a Senior Architect of .NET applications for large and mid-size organizations. Mark is a technology leader with Crowe Chizek in Indianapolis, Indiana. He specializes in architecture, design and development of Microsoft-based solutions. Mark was honored to be named a Microsoft MVP for application development with C#. You can reach Mark at email@example.com.