Design Studio Mag - The web design magazine for all - Exploring ASP.NET Application Configuration Data

The appSettings node of a Web.Config file is used specifically to store custom application data for your application using key/value pairs. This data can then be read out of the Web.Config file at runtime through the static AppSettings property that is a member of the ConfigurationSettings class in the System.Configuration namespace. The AppSettings property is a NameValueCollection object that uses the name of the key as the indexer for the collection. An example of a Web.Config file is shown below which stores the connection string to an Access database:

This file tells the ASP.NET runtime the following information about this application:

Custom settings for the application are stored in the appSettings node. As noted earlier, there is a key/value pair called DbConnString
Anonymous access is to be used as the authentication means for this application. This is accomplished setting the allow permission to “?” in the <authorization /> node of the config file. The “?” denotes anonymous access. If the value was an asterisk (*), the application would only allow users that have been authenticated using the ASP.NET Forms Authentication Module.
The default compile language for this application is C#. This can be overridden by a page directive language attribute, but the application’s default .NET language is C#.
Showing custom error pages is turned off. This means that any unhandled errors encountered at runtime will have the stack trace of the failure shown to all users. This is not recommended for production environments.
The encoding used for both responses and requests is UTF8.

This Web.Config file is a very simple demonstration of the capabilities of the Web.Config file. One of the things that make the Web.Config file such an attractive feature is that the config file is loaded from disk and the application is restarted any time that a change is made to the file. There is no need to reset the application in IIS; the ASP.NET runtime will do it for you.

Reading the data from the appSettings node of our config file is also a simple process. To demonstrate, we’re going to create an ASP.NET Web Form that will consist of a single Label control. We will then read the database connection string from the Web.Config file, and place the value in the Text property of the Label control on the page.

As you can see, reading a key/value pair set data from the Web.Config file is as simple as a single line of code. The Web.Config file also permits you to create your own custom configuration sections. A configuration section is very similar to the appSettings node, only the node can have a specific name and schema per your specification. You can then read the configuration using the GetConfig() method of the ConfigurationSettings object. The GetConfig() method accepts an XPath query as a string parameter, and will return a NameValueCollection object just like the AppSettings property of the ConfigurationSettings object. For more information on using Config Sections, visit: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcreatingnewsectionhandlers.asp

The ASP.NET Web.Config file may vary in complexity based on your application. We’ve only briefly discussed the power of the Web.Config file. For more information, visit the MSDN website and view the documentation found at the following address: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconformatofconfigurationfiles.asp

Application Data using a Custom XML File
In larger scale sites, it may be necessary to have sections of the site running in separate applications. In this type of production environment, the application data would need to be common among all applications. For this type of scenario, using Web.Config files for configuring the applications along with a separate XML file for application data is ideal. Using this method, the appSettings node will be omitted from the Web.Config files of our application.

The .NET Framework supplies us with some very handy tools to work with XML documents. We are going to create a class that will be used to read our application data from an XML file at runtime and allow us programmatic access to this data. The process of taking an XML document and turning it into a programmatic object is known as deserialization. By contrast, taking a programmatic object and turning it into XML is known as serialization. To begin, we are going to define an XML document as shown below:

The root element of our XML document will share the same name as our C# class, in this case: AppConfigData. Child elements of the root element will be exposed through public properties. The class definition for our AppConfigData object is shown below:

The structure of this class is actually quite simple. A default public constructor initializes the 3 properties of the class to empty strings. A default public constructor (no argument list) must be specified for any serialization/deserialization attempts. A method named Read() then actually performs the deserialization. Once the XML file has been deserialized to a local instance of the class, the values from the local instance of the class are assigned to the class properties.

To test our new class, we will once again create an ASP.NET Web Form only this time we will place 3 Label controls on the page to display our configuration data. To read the data, we will create a new instance of our AppConfigData object from inside the Page_Load() event handler and place the data from the AppConfigData object into the Text property of the Label server controls as shown below:

Using this type of implementation proves very powerful when you have multiple applications that share common application data. You can compile your C# AppConfigData class into a DLL and use it in several projects/applications. To add to the advantages, you only have to change one file to change the application data for several applications or even possibly several sites. ASP.NET applications also do not have to be reset to pick up the new configuration data. The new configuration data will be read in as soon as a new instance of an AppConfigData object is created.

Conclusion:
As you can see, you have several options for storing configuration data for use in an ASP.NET web application. When selecting an application data model for your ASP.NET web app, remember to factor in scale (number of applications using this data) and application availability, since ASP.NET apps must be restarted by IIS when changes of any kind are made to the Web.Config file.

Friday, 21 November 2008

our sponsors