A Word on the Metabase

only for RuBoard

The process for configuring the operating system and applications that run on it has evolved since MS-DOS' inception. To configure MS-DOS, AUTOEXEC.BAT and CONFIG.SYS files were used, and applications running on top of the operating system used their own proprietary configuration files. Back in the days of Windows 3.1, people were introduced to .INI files that stored configuration information. A set of simple APIs were included to work with .INI files in a standard fashion (remember GetProfileString and GetProfileSection ?). A simple tool called sysedit provided easy access to edit the SYSTEM.INI , WIN.INI , CONFIG.SYS , and AUTOEXEC.BAT files by simply loading all of them into a Multiple Document Interface (MDI) window.

When Windows NT 3.5 was released, everyone became more familiar with the registry. It wasn't until Windows 95 was released, however, that people saw the true ability to control the operating system, expecially with the release of PowerToys , an application designed to customize the Windows 95 UI. The registry allowed for easier development of hierarchical structures that could contain both text and binary data in several formats. The registry became favored over .INI files.

The release of Windows NT 4.0 increased the use of the registry. But when the Option Pack for Windows NT 4.0 was released (including IIS 3.0), developers quickly became intimately familiar with tweaking the registry to manipulate IIS for capabilities such as ADO connection pooling and connection timeouts. Microsoft's integration of some of these registry settings into the Microsoft Mangement Console (MMC) snap-in eased the developer's research time, but it was soon realized that using the registry for IIS management was not an optimal solution because of speed and complexity issues.

The solution to using the registry is provided by the metabase . The metabase is a binary file that provides hierarchical configuration information for Internet Information Services (IIS). It is located at %windir%\system32\inetsrv\MetaBase.bin . Several utilities are available for working with the metabase, including the Internet Services Manager MMC snap-in.

In ASP.NET, configuration information is stored in XML configuration files. These XML files can be modified while the server is running, and changes take effect without rebooting the web server. If you have ever had to go back to work at 3 a.m. to reboot the web server, you'll appreciate this new feature. The managed code configuration system reads the values and applies them without restarting the server. The exception to this case is the processModel section ”it's read directly by aspnet_isapi.dll . Changes do not take effect in this section until IIS is restarted.

Several configuration files are available that you can use with the .NET Framework: security configuration files, the machine configuration file ( machine.config ), and application configuration files.

Security Configuration Files

Security configuration files manage the permissions associated with a policy level and the code group hierarchy. These settings need to be modified using only the .NET Configuration MMC snap-in ( mscorcfg .msc ) or by using the Code Access Security Policy tool ( caspol .exe ).

machine.config

The machine configuration file, machine.config , specifies machine-wide settings. It contains settings for machine-wide ASP.NET, as well as assembly binding and built-in remoting channels. You can also specify custom settings in its appSettings section (described in the section, "Walk-Through of web.config's Hierarchical Structure"). It's recommended that application-specific settings be placed in their associated application configuration files unless they pertain to all applications on the machine.

Application Configuration Files

A benefit to using configuration files at the application level is that each application can configure the environment for its own use. For example, one of the settings available in a configuration file is the requiredRuntime setting in the startup section. It defines what version of the run-time to use. For machines with multiple versions of the common language run-time installed, this key can be used to manage on which version the application depends.

Two types of application configuration files exist: executable-hosted configuration files and web application configuration files ( web.config ).

Executable Configuration Files

Executable configuration files manage the configuration settings for the executable environment. The application configuration file is not compiled into the executable file as a resource file is. Rather, the configuration file is external to the application and uses the same name as the application with a .config extension. For example, an application named WindowsApplication.exe would have a single configuration file in its bin directory when it's compiled as WindowsApplication.exe.config . Unless this setting matches the executable name, the configuration file is not found.

web.config

When the application to be configured is a web application, the configuration file used is called web.config . When you create a new ASP.NET web application project in Visual Studio .NET, a web.config file is included in the list of files that is automatically generated.

Not only can the application's virtual root have a web.config file, but each subdirectory in the virtual directory can also have its own web.config file. Each web.config file applies its settings to its own virtual directory and its virtual subdirectories. If a conflict in settings occurs between a directory and a subdirectory, the settings in the subdirectory take precedence over the parent directory's settings. For example, look at the virtual directory structure in Figure 7.1.

Figure 7.1. Each subdirectory in the virtual directory might have its own `web.config` file.

Configuration Files Are Secured in ASP.NET

ASP.NET configuration files are secured and are not viewable through a browser: An attempt to access the web.config file causes an HTTP error, 403 (Forbidden).

The Public directory doesn't have its own web.config file: Settings are inherited from the parent Application directory.

The Secure directory, which represents the set of web pages that require authentication, uses its own web.config file separately from the parent Application directory. In this model, a conflicting setting in the Secure directory's web.config file would be used. Any settings not specifically overridden in the child directory would be inherited from the parent directory. This enables the developer to require a different authentication model for each subdirectory if desired, or to use the settings for the parent directory. This also prevents the user from duplicating custom application settings for each virtual subdirectory.

Take a look at the components of the web.config file and see what configuration options are available.

Configuration Settings Are URL Specific

Settings are inherited by subdirectories according to the URL, not the physical disk path .