Configuration Files

ASP.NET provides extensive support for configuring its behavior with the use of XML-based configuration files. Use of XML files to store configuration makes server-side administration easier for the following reasons:

  • XML files are plain-text files and can be modified using a simple text editor such as Notepad.

  • To apply configuration changes, all you need to do is copy these XML files to an appropriate location. The new settings automatically take effect and, in most cases, there's no need to stop and restart the ASP.NET process or reboot the computer.

graphics/note_icon.gif

If you change the <processModel> element in the machine.config file, you must restart Internet Information Services (IIS) for the changes to take effect. This element controls internal IIS settings such as which processors to use on a multiprocessor computer and the number of threads to allocate to ASP.NET.


graphics/alert_icon.gif

Although changes to configuration files are picked up automatically by ASP.NET, it doesn't mean that you can change things without consequences. When you change an application's configuration file, ASP.NET clears all the application state and session state variables for that application. If you change the web.config file for a particular site, ASP.NET clears the state settings for every application on the affected site. In addition, if you change the machine.config file, you lose all the state settings for every site on the Web server.


Anatomy of a Configuration File

The easiest way to learn about the structure of configuration files is to look inside one. Let's start with the master configuration file that configures ASP.NET's operations on the computer. Its name is machine.config , and you'll find it in the Microsoft .NET installation directory. For example, on Windows Server 2003, this file is at the following location:

 c:\windows\microsoft.net\framework\v1.1.4322\config\machine.config 

If you browse through the machine.config file on your computer, you'll get a sense of what you can configure in this fashion. The file includes some comments to show you the allowable options for settings. Table 16.1 lists the various sections you can specify in this (and other) configuration files.

Table 16.1. Configuration File Sections

Section

Used for

<allow>

Allows access to a resource

<assemblies>

Specifies the assemblies to use for dynamic compilation

<authentication>

Configures authentication

<authorization>

Configures authorization

<browserCaps>

Detects the user 's browser type

<clientTarget>

Specifies user agent aliases

<compilation>

Specifies the compiler settings

<compilers>

Specifies the supported compilers

<credentials>

Specifies the name and password credentials for authenticating users

<customErrors>

Specifies the custom error messages

<deny>

Denies access to a resource

<forms>

Configures forms-based authentication

<globalization>

Configures globalization settings

<httpHandlers>

Maps incoming requests to HTTP handlers

<httpModules>

Manages HTTP modules within an application

<httpRuntime>

Configures the HTTP runtime

<identity>

Configures the application identity

<pages>

Specifies the page-specific configuration information

<processModel>

Controls the ASP.NET process model

<protocols>

Contains protocols used to decrypt client data

<securityPolicy>

Maps security levels to policy files

<serviceDescriptionFormatExtensionTypes>

Specifies service description format extensions

<sessionState>

Configures session state options

<soapExtensionTypes>

Specifies SOAP extensions

<trace>

Configures application tracing

<trust>

Configures code access security

<user>

Defines users

<webServices>

Specifies the settings for Web services

graphics/note_icon.gif

For a complete list of what can appear in each element in a configuration file, see www.msdn.com/library/en-us/cpgenref/html/gngrfnetframeworkconfigurationfileschema.asp.


The Configuration File Hierarchy

Configuration files are treated as a hierarchy by ASP.NET. The machine configuration file ( machine.config ) controls settings for the entire computer. Settings in machine.config can be overridden for a particular Web site hosted on the computer by a configuration file ( web.config ) located in the root folder of that Web site. Those settings themselves can be overridden for a particular Web application (virtual directory) by an application-specific configuration file ( web.config ). These settings, in turn , can be overridden by a configuration file ( web.config ) that applies to only part of an application.

For example, if you have a URL such as http://localhost/AppDir/SubDir/default.aspx , the code executing in default.aspx could be affected by the following configuration files, in this order:

  1. The machine.config file

  2. The web.config file in the root directory of the localhost Web server

  3. The web.config file present in the application's root directory AppDir

  4. The web.config file present in the subdirectory SubDir

At any time, the web.config file closest in the folder chain to the page being displayed overrides the similar settings defined in the other configuration files. Several other factors complicate this simple picture of how things work, including

  • A setting in a configuration file can be marked with a location element ” For example, you might tag a particular section with the element <location path ="Subdir1"> . Settings contained in this element will apply only to pages stored in the Subdir1 subdirectory of the application.

  • ASP.NET configuration files apply only to ASP.NET resources ” For example, any HTML page remains unaffected by the settings in the configuration files.

  • Any configuration file can mark an element with the allowOverride="false" attribute ” In this case, more specific configuration files cannot override this setting.

Reading Configuration Settings from Code

The .NET Framework also provides programmatic access to the configuration files. For example, say you have defined a custom key in the <appSettings> element as follows :

 <appSettings>   <add key="Custom" value="Custom configuration value" /> </appSettings> 

You could therefore read it in your program using the following expression:

 ConfigurationSettings.AppSettings["Custom"] 

To read one of the built-in values, you need to know which object in the ASP.NET object model consumes that setting. For example, the Mode property of the Session object exposes the value of the mode attribute of the <sessionState> element in the configuration file. The Mode property can be accessed using the following expression:

 Session.Mode 


MCAD Developing and Implementing Web Applications with Visual C#. NET and Visual Studio. NET (Exam [... ]am 2)
MCAD Developing and Implementing Web Applications with Visual C#. NET and Visual Studio. NET (Exam [... ]am 2)
ISBN: 789729016
EAN: N/A
Year: 2005
Pages: 191

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net