Configuration Inheritance
When the server receives a request for a particular Web resource, ASP.NET computes the configuration settings for that resource hierarchically, using all the configuration files located in the virtual directory path for the requested URL. For example, you could have a Web site with the following file structure, where the application root directory is the application virtual directory (Vdir).
.gif "dtbwsx8s.folders2(en-us,VS.71).gif")
Normally, the last configuration setting overwrites settings for the same section provided in parent directories, but the section handler might implement a different inheritance scheme.
For example, as the administrator, you could configure the application settings to allow all users access to the ASP.NET resources in the application root directory (the physical directory mapped by the application virtual directory) but allow only selected users access to the ASP.NET resources in the two subdirectories.
Assume that there is a Web.config file in the SubDir1 directory and none in the application root or SubDir2 directories. In this case, ASP.NET is using two configuration files. The highest-level file is the one located in the systemroot\Microsoft .NET \Framework\versionNumber\CONFIG directory. This file, named Machine.config, is at the machine level, and all ASP.NET directories and subdirectories inherit its settings. Machine.config is shipped with the.NET Framework and contains many default ASP.NET settings. The default setting for the security configuration section of this file allows all users to access all URL resources. There is no configuration file in the example's application root directory that modifies security, so all users have access to the ASP.NET resources in it (because that directory inherits from the machine-level configuration file). If the Web.config file in the SubDir1 directory contains a security configuration section that allows access only to certain users, then SubDir2 inherits that setting. So, all users have access to the ASP.NET resources in the application root directory, but only certain users have access to the ASP.NET resources in SubDir1 and SubDir2.
Configuration settings for virtual directories are independent of physical directory structure, and virtual directories must be organized carefully to avoid configuration problems. For example, you could have an application named MyResource.aspx with the following physical directory structure.
C:\Subdir1\Subdir2\MyResource.aspx
Assume a configuration file is located in Subdir1 and a virtual directory named Vdir1 is mapped to c:\Subdir1 and a virtual directory named Vdir2 is mapped to c:\Subdir1\Subdir2. If a client accesses the resource physically located at c:\Subdir1\Subdir2\MyResource.aspx using the URL https://localhost/vdir1/subdir2/MyResource.aspx, the resource inherits configuration settings from Vdir1. However, if the client accesses the same resource using the URL https://localhost/vdir2/MyResource.aspx, it does not inherit settings from Vdir1. Therefore, creating virtual directories in this manner could cause unexpected results or even an application failure and is not recommended.
Note The ASP.NET configuration system applies only to ASP.NET resources (those registered to be handled by ASP.NET using the Aspnet_isapi.dll). The configuration system does not provide authorization for non-ASP.NET resources by default. ASP, HTML, TXT, GIF, and JPEG files, for example, are accessible by all users. In the preceding example, if directory browsing is enabled and no other restrictions are in place, all users can view non-ASP.NET files located in the application root directory, SubDir1, and SubDir2. For more information about ASP.NET security, see Securing ASP.NET Web Applications.