Centralized Configuration

The section has two attributes: Path and allowOverride. The Path attribute represents the virtual path to which the embedded settings apply. The following snippet shows how it works. The code shown is taken from a web.config file. Note that the name of the folder must be relative and should not begin with slashes, backslashes, or dots.

The defining characteristic of this approach is that you have a single, centralized web.config file to maintain and can still configure subdirectories individually and independently. This feature saves you from the burden of maintaining several web.config files, but it also introduces some unpleasant side effects that in the long run can turn out to be quite harsh. For example, any change to the file results in a new compilation for all the pages in the application. If you maintain distinct web.config files, the compilation occurs only for the pages really affected by the change.

Note

If the path attribute is omitted in the element, the embedded settings will apply to all subfolders of the application in the case of an application’s root web.config. Settings will affect all installed applications on the server machine if the element that is missing the path attribute is found in the site’s root web.config or machine.config.

Machinewide Settings

Used within the machine.config file or the site’s root web.config file, the element lets you specify different machinewide settings for all the Web applications hosted on the server machine. Note that in this case, though, you must indicate the name of the application you’re configuring prefixed by the IIS name of the Web site. The Web site name is read in the IIS Manager. The following script applies to the YourApp application in the default Web site:

When you develop the ASP.NET code, you typically test it on a development machine with its own copies of machine.config and site web.config files. When you deploy the application on a production box, especially in an ISP scenario, you might not be able to restore the same settings. One possible reason is that the administrator does not want you to modify the current settings because they work well for all other applications or because of security concerns.

You can work around the issue by simply replicating any needed global settings into the application’s root web.config. If you are deploying your code to a service provider, you might find that many configuration elements have been locked down and cannot be overridden. (I’ll say more about this aspect in a moment.) In this case, a new application-specific section created in machine.config or the site’s web.config can contain all the machine settings needed for your application without breaking others.

Whenever possible, though, you should try to replicate needed changes into the application’s web.config. This should always be the first option considered because it makes the entire application self-contained.

Unmodifiable Settings

The second attribute you can specify—allowOverride—allows you to lock some settings at either the machine or application level. By grouping settings in a element with the allowOverride attribute set to false, you tell the ASP.NET configuration system to raise an exception whenever a protected setting is overridden in a lower-level configuration