第 114 页

file at a lower level will override the same sections specified in a file higher up the chain. If no

configuration file defines a value or section, the default values are taken from the schema files

to which the configuration files must adhere.

Machine config

At the root of the inheritance model is the machine.config file (located in the systemroot\

Microsoft .NET\Framework\versionNumber\CONFIG\ folder, or systemroot\Microsoft .NET\

774 .

chaPter 36 conFigurATion FileS

Framework64\versionNumber\CONFIG\ for 64-bit machines), which defines configuration settings for

the entire system. All configuration files inherit from this file and can override these settings.

web config

Web applications are confi gured via the web.config fi le. This fi le can be located in a number of

locations, depending on the scope to which the settings need to be applied. To apply a confi guration

to all web applications on a machine, place the web.config fi le in the same directory as the

machine.config fi le. In most cases the settings need to be applied at a much fi ner granularity. As

such, the web.config fi le can also be placed in any virtual directory or subdirectory to control web

applications at that level. If it is placed in the root folder for a web site, the confi guration will be

applied to all ASP.NET applications in that web site.

A word of caution: When you are working with virtual directories that do not align with the

directory structure on the computer, it’s possible to have an application that has different

configurations depending on how it is referenced. For example, consider C:\inetpub\wwwroot\

MainApplication\Contacts\Contact.aspx, which has been set up with both MainApplication

and Contacts as virtual directories. You can reference the contact page as either:

http://localhost/MainApplication/Contacts/Contact.aspx

or:

http://localhost/Contacts/Contact.aspx

In the first case, the configuration settings that are applied are inherited from the MainApplication

folder and may be overridden by a configuration file in the Contacts folder. However, in the second

case, settings are applied only from the configuration file within the Contacts folder.

Making changes to a web.config file causes the ASP.NET application to be

restarted. This is quite an effective way to force a web application to flush its

cache and behave as if it were being accessed for the first time, without having to

restart the entire server.

app config

Windows applications can be configured via an application configuration file, which also inherits from

machine.config. Because the output assembly name is known only when an application is compiled,

this file starts off as app.config and is renamed to application.exe.config as part of the build

process. For example, an application with AccountingApplication.exe as the main executable

would have a configuration file entitled AccountingApplication.exe.config. This configuration

file is automatically loaded based on its name when the application is loaded. If an app.config files is

added to a dll, it will be renamed to assembly.dll.config during the build process.

Configuration schema .

775

security config

In conjunction with the application configuration files are a number of security configuration files.

These also follow an inheritance path but across a different dimension. Instead of being application-

focused, the security configuration files are broken down into enterprise (Enterprisesec.config),

machine (Security.config), and user (Security.config). The enterprise- and machine-level files

are both stored in the same location as the machine.config file, whereas the user-level file is stored

under the user-specific application data folder.

applicationhost config

IIS7 changes the way configuration information is stored to use a set of configuration files that

work in parallel with those for ASP.NET and the .NET Framework. Because IIS and the .NET

Framework are versioned independently, configuration information specific to the individual

technologies are held in the machine.config/web.config and the applicationHost.config

files, respectively. However, because there is an interrelationship between IIS and ASP.NET, the

applicationHost.config file does fit into the configuration file inheritance hierarchy. Because

the applicationHost.config file is specific to an instance of IIS, it fits into the inheritance

hierarchy after both the machine.config and web.config files located at the machine level (that

is, located in the systemroot\Microsoft .NET\Framework\versionNumber\CONFIG\ folder).

The applicationHost.config file can be found in the systemroot\System32\InetSrv\Config

folder, and the corresponding schema files can be found in the Schema subdirectory. There are also

administration.config and redirection.config files in this folder that are responsible for IIS

feature delegation and configuration file redirection, respectively.

confiGuration scheMa

A configuration file, whether it is a machine.config, a web.config, or an application

configuration file, needs to adhere to the same configuration schema that determines which

elements should be included. The schema is located at C:\Program Files\Microsoft Visual

Studio 10.0\Xml\Schemas\DotNetConfig.xsd (C:\Program Files (x86)\Microsoft

Visual Studio 10.0\Xml\Schemas\DotNetConfig.xsd on 64-bit machines) and is broken

down into a number of sections.

section: configurationsections

Configuration files can be customized to contain any structured XML data. In order to do this, you

must define a custom section in the configurationSections block within the configuration file.

This defines both the name of the configuration section and the class that is to be called in order to

process the section.

The configurationSections section in the machine.config file defines the handlers for each of

the standard configuration sections discussed here. You can define your own configuration sections

in your application configuration file so long as you specify which class will be used to validate and

process that section. For example, the following code snippet defines the section handler for the

ConfigurationApplication.My.MySettings configuration section, along with the corresponding

776 .

chaPter 36 conFigurATion FileS

section. The schema of this section must correspond to what the System.Configuration

.ClientSettingsSection class expects, rather than the normal configuration file schema.

<configuration>

<configSections>

<section name="ConfigurationApplication.My.MySettings"

type="System.Configuration.ClientSettingsSection,

System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

requirePermission="false" />

</configSections>

.

<ConfigurationApplication.My.MySettings>

<setting name="PrimaryServer" serializeAs="String">

<value>www.builttoroam.com</value>

</setting>

</ConfigurationApplication.My.MySettings>

</configuration>

It is also possible to include configSections in a sectionGroup element that can be used to help

lay out configuration information. The preceding example can be extended as follows:

<configuration>

<configSections>

<sectionGroup name="applicationSettings"

type="System.Configuration.ApplicationSettingsGroup,

System, Version=2.0.0.0, Culture=neutral, PublicKeyToken= b77a5c561934e089" >

<section name="ConfigurationApplication.My.MySettings"

type="System.Configuration.ClientSettingsSection,

System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

requirePermission="false" />

<section name="ReferencedAssembly.My.MySettings"

type="System.Configuration.ClientSettingsSection,

System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

requirePermission="false" />

</sectionGroup>

</configSections>

.

<applicationSettings>

<ConfigurationApplication.My.MySettings>

<setting name="PrimaryServer" serializeAs="String">

<value>www.builttoroam.com</value>

</setting>

</ConfigurationApplication.My.MySettings>

<ReferencedAssembly.My.MySettings>

<setting name="SecondaryServer" serializeAs="String">

<value>www.peaksite.com</value>

</setting>

</ReferencedAssembly.My.MySettings>

</applicationSettings>

</configuration>

Where used, the configSections element must appear as the first child of the configuration

element.

Configuration schema .

777

section: startup

The startup configuration section determines the version of the framework that is either required

(requiredRuntime) or supported (supportedRuntime) by the framework. By default, a .NET

application will attempt to execute using the same version of the framework on which it was built.

Any application being built with support for multiple versions of the framework should indicate this

with the supportedRuntime element, defining the most preferred framework version first:

<configuration>

<startup>

<supportedRuntime version="v4.0.20409"/>

<supportedRuntime version="v2.0.50727"/>

<supportedRuntime version="v1.1.4322"/>

</startup>

</configuration>

This configuration section would be used by an application that has been tested for versions 4.0,

2.0, and 1.1 of the .NET Framework. Anomalies were detected in the testing for version 1.0 of the

.NET Framework, so it has been omitted from the supportedRuntime list. The version number must

correspond exactly to the installation directory for that framework version (for example, version 4.0

of the .NET Framework typically installs to C:\WINDOWS\Microsoft.NET\Framework\v4.0.20409\).

section: runtime

Garbage collection is a feature of the .NET Framework that distinguishes it from non-managed

environments. The process of collecting and disposing of unreferenced objects is usually done in

parallel with the main application on a separate thread. This means that the user should not see

any performance issues as a result of this process being run. However, there may be circumstances

when this process should be run inline with the main application. The runtime section of the

configuration file can be used to provide limited control over how the .NET runtime engine operates.

Among other things, you can specify whether the garbage collection should be done concurrently

with the main application.

This section can also be used to specify a location in which to search for assemblies that may be

required by an application. This attribute can be useful if an application references assemblies that

are in a non-standard location. The following code illustrates the use of the codeBase attribute to

locate the ImportantAssembly.dll, as well as to dictate that garbage collection be done inline with

the main application thread:

<configuration>

<runtime>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<dependentAssembly>

<assemblyIdentity name="ImportantAssembly"

publicKeyToken="32ab4ba45e0a69a1"

culture="neutral" />

<codeBase version="2.0.0.0" href="./ImportantAssembly.dll"/>

</dependentAssembly>

</assemblyBinding>

778 .

chaPter 36 conFigurATion FileS

<gcConcurrent enabled="false"/>

</runtime>

</configuration>

section: system runtime remoting

The remoting section of the configuration file can be used to specify information about remote

objects and channels required by the application. For example, the default HTTP channel can be

directed to listen to port 8080 by means of the following configuration snippet:

<configuration>

<system.runtime.remoting>

<application>

<channels>

<channel port="8080" ref="http"/>

</channels>

</application>

</system.runtime.remoting>

</configuration>

section: system net

Because of the current demand for more secure operating environments, organizations often use

proxies to monitor and protect traffic on their networks. This can often result in applications

not functioning correctly unless they have been configured to use the appropriate proxies. The

networking section of the configuration files can be used to adjust the proxy that an application

uses when making HTTP requests.

The .NET Framework ships with an SmtpClient class that can be used to send mail from within

an application. Obviously, doing this requires information such as the server and the credentials

to use when sending mail. Although such information can be hard-coded within an application, a

more flexible approach would be to specify it in a configuration file that can be adjusted when the

application is deployed. The following configuration snippet illustrates the use of the default proxy

(although it bypasses the proxy for local addresses and the DeveloperNews web site) and specifies

the default SMTP settings to be used by the SMTP client:

<configuration>

<system.net>

<defaultProxy>

<proxy usesystemdefaults="true"

proxyaddress="http://192.168.200.222:3030"

bypassonlocal="true" />

<bypasslist>

<add address="[a-z]+\.developernews\.com" />

</bypasslist>

</defaultProxy>

<mailSettings>

<smtp deliveryMethod="network">

<network host="smtp.developernews.com"

port="25" defaultCredentials="true" />

</smtp>

Configuration schema .

779

</mailSettings>