Section 9.4. XML-Based Configuration

9.4. XML-Based Configuration

You configure applications in .NET primarily through XML files. This is replacing previous, more cryptic stores such as the Windows registry or a database. If you are involved with .NET and are not yet familiar with XML, I recommend you purchase a good book to study it. All settings within the .NET Framework can be managed through XML configuration files, and the IIS metabase is moving in the same direction, too. I recommend Microsoft ASP.NET Setup and Configuration Pocket Reference (Microsoft Press). This work provides outstanding detail into the management of ASP.NET applications. It is a reference guide that covers ASP.NET along with a good amount of general .NET information.

9.4.1. Configuration Types

The .NET Framework defines two types of XML configuration files: Security Policy and Settings.

9.4.1.1 Security Policy

Security Policy files define the code access security policy, which specifies what type of actions code is allowed to perform. I will cover code access security in detail later in this chapter.

These files are far too big and ugly to display here. I strongly recommend using the .NET Configuration MMC, pictured in Figure 9-1, to administer these files.

Figure 9-1. .NET Configuration MMC

9.4.1.2 Settings

Settings files are probably the most exciting breakthrough in .NET from a management perspective. These files have consolidated all application settings into a single repository, providing a well-defined bridge between system administrators and developers.

The .NET Framework defines sections of the file to configure everything from the runtime to cryptography through these files. The entire schema is far too complex to show here; however, Table 9-2 describes the core sections defined by the framework.

Table 9-2. Configuration file sections

Section	XML tag	Description
Startup	<startup>	Specifies the required and supported runtime versions. Typically used at the application level.
Runtime	<runtime>	Configures assemblies and garbage collection.
Remoting	<system.runtime.remoting>	Configures Remoting, the .NET remote procedure call (RPC) technology similar to DCOM.
Network	<system.net>	Configures network access. Can define proxy servers, limit connection count, etc.
Cryptography	<mscorlib> <cryptographySettings>	Used at the machine level to specify the cryptography providers on the system. Would not be specified at the application level unless custom cryptography providers were utilized.
Configuration Sections	<configSections>	This section defines other sections in the configuration file. At the machine level, the other core sections are defined. At an application level, custom sections can be defined.
Trace and Debug	<system.diagnostics>	Configures the level and output of tracing and debugging.
ASP.NET	<system.web>	The most in-depth section. Provides security, state, error handling, and many other configuration parameters for web applications.
Application Settings	<appSettings>	A list of name-value pairs to be used within an application. The application must be developed to look in this section for values.

Example 9-1 shows a typical settings file for a web application. As you can see, the file is quite descriptive of itself through a well-defined hierarchy and semantics.

Example 9-1. Typical web.config file

<configuration>       <system.web>     <pages enableSessionState="false" enableViewState="false" />     <compilation defaultLanguage="C#" debug="false"/>     <customErrors mode="RemoteOnly">       <error statusCode="404" redirect="pageNotFound.aspx"/>     </customErrors>     <httpRuntime executionTimeout="240" maxRequestLength="8192" />   </system.web>        <appSettings>     <add key="application.name" value="Test Application" />     <add key="application.url" value="http://www.test.com" />     <add key="administrator.name" value="Mr. Administrator" />   </appSettings>     </configuration>

9.4.2. Configuration Scopes

When an application is executed, the XML configuration files are arranged and evaluated in a chain starting with the widest scope, Enterprise, going down to the finest scope, Application. This allows a refined hierarchy of management starting with the system administrators, and extending to the users and developers, when allowed.

9.4.2.1 Enterprise

The Enterprise scope exists to define a security policy that is applicable to the entire enterprise. Despite the policy's scope, the configuration file must exist on each machine to be enforced. The configuration file is located at %SystemRoot%\Microsoft.NET\Framework\<version>\CONFIG\enterprisesec.config. By default, no security is defined in this scope.

9.4.2.2 Machine

The Machine scope has a settings file in addition to another level of security policy.

The Machine settings file, machine.config, is located at %SystemRoot%\Microsoft.NET\Framework\<version>\CONFIG\machine.config. The machine.config provides a multitude of setting defaults, as it is the root of the settings hierarchy. This file is very well-commented, providing easy edit capability. You always should back up this file before editing, as there is no undo functionality.

The Machine security policy file, security.config, is located at %SystemRoot%\Microsoft.NET\Framework\<version>\CONFIG\security.config. All code access security is applied in this file by default.

9.4.2.3 User

The User scope, like the Enterprise scope, defines security policy only. The configuration file is located at %UserProfile%\Application Data\Microsoft\CLR Security Config\<version>\security.config. By default, no security is defined at this scope.

9.4.2.4 Application

The Application scope defines settings for the application. No code access security policy exists for the Application scope. The name and location of the configuration files depend on the type of application.

ASP.NET web applications use files named web.config. These files can be present in any directory within the application. As a page is executed, all web.config files within the page's directory structure are applied in the order of shallowest to deepest. For example, I'll use an application with the root C:\Inetpub\wwwroot\ and a page with the path C:\Inetpub\wwwroot\subdirectory\page.aspx. A web.config file is present in both the application root and the subdirectory with the page. The web.config file from the root directory is applied first. The web.config file from the subdirectory is applied next, overriding any conflicting settings in the web.config file from the root directory.

Executable-based applications use a configuration file in the same directory as the executable. The filename is the executable name with .config appended to it. An example is application.exe.config. Executable-based applications include Windows Forms, Windows Service, and Console applications.

Applications hosted inside Internet Explorer must specify the location of the configuration file through a <link> tag within the <head> tag of the web page. You can do this in the following format:

<html>  <head>   <link rel="application.dll.config" href="application.dll.config" /> ...