Are you confused by the numerous options available with ASP.NET 2.0 configuration files? Tony Patton helps you make sense of how ASP.NET 2.0 uses machine.config and web.config configuration files.
Configuration files are an important aspect of .NET development. ASP.NET applications have web.config and other configuration files, while non-Web applications have app.config. Here's a closer look at how ASP.NET 2.0 uses configuration files (specifically machine.config and web.config).
ASP.NET 2.0 includes a number of configuration files with a standard .NET installation. The following list provides an overview of these files:
- enterprisesec.config: Configures enterprise-level security policies.
- security.config: Configures machine-level security policies.
- machine.config: Establishes how .NET will run on the entire machine. It holds the default settings for the installation, and you can edit these settings to tailor your environment.
- web.config: Modifies the default settings established in the machine.config file.
You will find the first three in the following system directory:
[.NET version number]\config
For example, the files may be found in the following directory on my development box, which has the .NET Framework 2.0 installed on the C drive in the default directory:
Notes: This article focuses primarily on machine.config and web.config; I will cover the security-related files in a future article. Also, if you browse the previously mentioned config directory, you'll notice additional files with the config file extension. The security policy files are beyond the scope of this article.
Configuration files are basic text files, so you can easily edit or view them with your favorite text editor. One issue to watch is that you need to ensure the editor saves the file with the proper .config file extension. Also, you should always create a backup before making changes.
ASP.NET does configure IIS to prevent direct browser access to web.config files so the files' contents are not publicly available. This is an important detail since many developers store connection information, including username and password, in web.config files. With a standard ASP.NET installation, any attempt to access web.config files generates a 403 (Access Forbidden) error.
An ASP.NET machine contains only one instance of the enterprisesec.config, security.config, and machine.config files, but the number of web.config files depends on application design.
It's important for you to understand how the system uses its configuration files (i.e., how the system processes machine.config and multiple web.config files).
A Web.config file applies its configuration settings to the directory in which it is located, as well as all virtual child directories under it. Directories beneath it may contain their own web.config file, which will override the parent's configuration. That is, settings are hierarchically modified, with each subdirectory having the chance to override the settings from its parent directory.
The following is an example of an application URL:
The .NET Framework is installed on the C drive in the default directories. Using this example page URL and setup, ASP.NET 2.0 applies configuration options in the following order:
machine base configuration settings are retrieved. This configuration file
can be found at:
root web configuration for the machine is used (if it exists). It is found
configuration settings for the site or root application are applied. This
file will apply to all sites or applications on IIS. The file is located
specific application settings (applicationname in this example) are
applied. If the application uses a virtual directory mapped to
c:\applicationname, then the configuration file may be found at:
configuration settings for the specific directory (subdirectory in this
example) are applied (if they exist). The application uses a virtual
directory mapped to c:\applicationname, so the configuration file may be
ASP.NET 2.0 loads the configuration file details into memory when the application starts and reloads the settings when/if any changes are made to the configuration files.
Avoid multiple files
The .NET Framework provides an option if you don't want to litter IIS with countless web.config files. You can use the location element within the web.config file to identify path-specific configuration settings. You would place this within the main web.config file (this may be in the application's root directory, the server's default configuration file, or whatever works best for the application).
The location element is placed within the file with a path attribute that points to the subdirectory to which it applies. Also, an allOverride attribute lets you specify whether another configuration file can override the settings.
Know your options
The myriad of options available with ASP.NET 2.0 configuration files can be a bit overwhelming. Don't despair—you will not be confused once you have a clear understanding of how the system processes the files. Knowing what changes to make and where to make them is imperative to the proper functioning of an application.
Have you had problems or issues when dealing with ASP.NET 2.0 and configuration options? Share your experiences with the .NET community by posting to the article discussion.
Miss a column?
Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.
Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.