This chapter is from the book

This chapter is from the book

Throughout this book, it's been shown that .NET incorporates XML into
key areas of the .NET Framework, as well as into technologies, such as ADO.NET.
This chapter discusses how XML is integrated with the configuration of Windows
Forms and Web Forms applications.

A Word on the Metabase

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.

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.

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).

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

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.