ASP.NET provides a convenient, extensible, XML-based mechanism for configuring ASP.NET and applications that run under it. It is an improvement over the IIS metabase that was awkward to change, required IIS to be restarted, and was not easily replicated on additional servers. By contrast, ASP.NET automatically detects changes to the web.config file and transparently restarts the application; there is no need to restart IIS. Replicating an ASP.NET application configuration is as simple as copying the web.config file to the new server.
Configuration File Hierarchy
ASP.NET uses a hierarchy of configuration files. The machine.config file contains the settings for the server and is located in the %SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\ folder. You can create web.config files to configure each of your applications, overriding the settings in machine.config. Folders within the application can have web.config files to customize the configuration of portions of the application and override the settings in the .config files higher up the hierarchy.
Structure and Use of web.config
The basic structure of web.config has a format similar to machine.config. The idea is that you add to web.config only those entries for which you want to override settings in machine.config. At a minimum, web.config must have a <configuration> element and a child element, such as a <system.web> element. The following is a minimal web.config file:
<?xml version="1.0"?> <configuration> <system.web> </system.web> </configuration>
The <configuration> and <system.web> elements don't do anything special other than provide the structure for other settings you want to add. By using child elements of these default configuration elements in web.config, you can, for example, change the ASP.NET HTTP runtime settings, store key/value pairs in the <appSettings> element of web.config, and add elements of your own to web.config. The recipes in this chapter will show you how to do all these things and more.
The web.config file is an XML file and can be edited with any text editor. As with most XML, the structure of the web.config file must conform to a defined schema. (In this case, the schema is detailed in the Microsoft documentation.) The web.config must be a properly formed XML document. In other words, elements must be placed in the correct sections of the XML document and conform to the case style and exact spelling defined in the schema. If a web.config file deviates from the schema in any detail, ASP.NET will throw a configuration error exception.
This chapter does not attempt to address all of the configuration settings available in machine.config and web.config. Rather, it provides information on many commonly used features and several that are poorly documented. Many other configuration parameters related to security and HTTP handlers are addressed in Chapters 9 and 20, respectively.
Finally, with regard to changes for ASP.NET 2.0, a handful of new attributes have been added to the <sessionState> settings in web.config, making it easier, for example, to control the behavior of cookies. Additionally, ASP.NET 2.0 offers new classes for reading, accessing, and modifying the contents of web.config. Beyond these enhancements, however, the basic strategies for working with machine.config and web.config are little changed from ASP.NET 1.x.