LANGUAGES: VB .NET
Manage App Settings With web.config: Part I
Master the essentials of web.config, and make your apps read it.
By Don Kiely
One ongoing question in application development, particularly in Web development, is where to save application configuration data. Over the years, we've used text files, databases (begging the question of where to store connection information), hard coding, and, in the Windows world, the system registry. Each has its pros and cons, but none was ever completely satisfactory.
In .NET, Microsoft has completely redesigned how developers can store application configuration information, providing flexible tools that let you make settings apply machine-wide or only to specific applications, have a hierarchical nature that gives you fine control over the scope of a setting, and some flexible ways to customize the whole structure to your particular needs. These customization features are the subject of this series of columns.
Configuration Settings Essentials
I assume you have a basic understanding of how ASP.NET configuration files work and that you've explored both an application's web.config file - perhaps adding some custom settings in the appSettings section - and machine.config. In particular, I assume you understand the benefits of using these ASP.NET features for configuration settings. Once you've used them, you'll never stuff any application data into the registry ever again!
But there are a few structural and development features you need to be crystal clear on to understand custom application settings. I'll cover these essential basics here.
The first important concept is that the files are hierarchical. This means all configuration settings begin in machine.config, which essentially provides the default settings for the entire server. Each application configuration file starting at the application root and down through any subdirectories can override the settings at a higher level. The only exception is when you can't override the setting at a higher level.
Another essential basic is that every section in the configuration file - that is, every child element of the root <configuration> element in a .config file - must be defined as a configuration section. This means every section, including the <system.web> section you see in most web.config files, and certainly all the default files VS .NET creates. You must include a <section> definition for simple sections or perhaps a <sectionGroup> for more complex sections. (Don't worry yet about the details; I'll get to them later.)
But if you look in a typical web.config file, you likely have either <appSettings> and/or <system.web> sections in use with no <section> or <sectionGroup> elements. The reason is they are listed in machine.config. Remember that anything there applies to all Web applications on that server. By placing these definitions there, you don't have to repeat them in every web.config file. Here is the <section> I have in my framework 1.1 machine.config:
The name attribute defines the name of the section and the type attribute tells .NET what class to use to read the settings. In this case, it uses the NameValueFileSectionHandler class in the System assembly to read the NameValueCollection located there. Keep this in mind. If you find yourself using the same custom section repeatedly, you might want to consider defining it in machine.config rather than in every web.config file.
If you've used the appSettings section in applications, you've probably used the ConfigurationSettings.AppSettings property to read the name value pairs from this section. For example, if you store a database connection string to web.config, your file might look something like this:
<add key="Connect" value="data source=(local);..." />
In this case, your code can read the connection string like this in VB .NET (it's the same in C# other than the syntactical adaptation):
Dim sConnect As String = ConfigurationSettings.AppSettings("Connect")
You can have as many of these key/value pairs as you want, referring to them by name in the AppSettings property.
It's pretty simple, and it's essentially the same in C#. But the AppSettings property is a special case because this section is designed for quick and dirty configuration settings use. Later in this series you'll see how to use the equivalent GetConfig method for custom sections. Next time, I'll continue by exploring the System.Configuration namespace.
The sample code in this article is available for download.
Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, Alaska. E-mail him at mailto:[email protected].