Configuration Hierarchy ASPNET


Nov 5, 2013 (3 years and 7 months ago)


Configuration Hierarchy ASPNET

Configuration in ASP.NET is managed with XML configuration files. All information needed to configure
an ASP.NET application which includes both core settings and application
specific custom settings is
stored in these
configuration files.

Compared to traditional ASP configuration, ASP.NET configuration files have many advantages:


You can update configuration files at any time, even when the application is running on the
server. ASP.NET will smoothly transition to a new
application domain to let newly updated
configuration take effect.


Configuration files can be easily updated. You can access them from a remote machine or upload
a new version via FTP. Copying same configuration files to multiple servers running the same
pplication, you can let them apply the same setting without pain.


Configuration files are plain XML files and human
readable. Thus you can understand quickly and
update them in place without using any third
party configuration tools.

To dig into ASP.NET co
nfiguration hierarchy, let us first go thorough each configuration file.

The machine.config file

This file machine.config resides in a directory looks like
Config on your hard disk. It defines supported
ation file sections, configures the ASP.NET worker process and registers providers that can be
used for advanced features such as membership, security and profiles.

To better understand settings specified in machine.config, you can open the machine.config.
file in the same directory. It contains both settings and descriptive comments to help you learn about
which functionality each setting section is for.

Root web.config file

ASP.NET has a root web.config file in the same directory along with the ma

file. It contains
additional settings to machine.config. These settings register ASP.NET core HTTP handlers and modules,
set up rules for browser support and define security policy.

All the web applications on the machine inherit the settings
in the machine.config file and root
web.config file. Note that most of these settings will never be touched in a web developer's life. And
some of the settings will be ignored when your web application is deployed to IIS because they are
override by IIS co
nfiguration file named ApplicationHost.config in IIS' directory.

Application web.config file

Every application inherits settings from machine.config and root web.config. However, you can still
apply additional settings to individual web application such as

authentication, debugging and custom
error page with a new web.config file in the root virtual directory of your web application. Moreover,
you can even place extra web.config files in sub
directories of your web application to configure
based s

It's important to keep in mind that web.config in web application cannot override all settings in
machine.config. For instance, process model settings cannot be changed on a per
application basis.
Fortunately, most settings are application
ic so you can set them in your application's web.config
file. But when come to your extra web.config files in sub
directories, some of the settings available in
root web.config have no effect in sub

As this article is more about configuration
hierarchy and inheritance, details on how the setting sections
work and what are they working for will not be discussed here. If you are interested in settings, you can
refer to MSDN, for example:

Configuration Inheritance

Here comes the fun part. ASP.NET uses a multiple
layered configuration system that allows you to use
different settings for different par
ts of your application. When you create additional sub
inside your application virtual directory, these sub
directories can contain their own web.config files
with additional settings. ASP.NET uses configuration inheritance so that each sub
ectory acquires the
settings from the parent directory.

For example, if you have a website and a page at http://localhost/1/2/3/page.aspx, then when
page.aspx is requested, multiple levels of settings will be invoked hierarchically.


Settings in
machine.config are applied first.


Then settings in computer root web.config are applied. Remember this root web.config is in the
same directory with machine.config.


If there is a web.config in your application root, settings in it are applied next.


If ther
e is a web.config in folder 1, settings in it are applied next.


If there is a web.config in folder 2, settings in it are applied next.


Finally if there is a web.config in folder 3, settings in it are applied last.

Note that settings applied in step 1 and 2

have special significance because certain settings such as
Windows account used to execute application can only be applied at machine.config level. And there are
settings for instance authentication mode which can only be applied at application root level

As a result, sub
directories can specify just a small set of settings that differ from the rest of the web
application. But you may still want to use directory
based web.config to apply different security settings.
You can put files that need to be secur
ed in a special folder with a web.config in it which restrict users
and roles have the privilege to access them.

If settings conflict, the settings from a web.config in a nested directory always override the settings
inherited from the parent (Closer one h
as a higher priority). However, you can designate specific locked
sections in a web.config so that it cannot be changed by a nested web.config. For example:




Unprotected settings which can be override by a neste
d web.config file






Settings here are locked