ASP.NET Configuration Sections

ASP.NET has several configuration section handlers for defining configuration settings within the <system.web> section of Web.config files.

The following sections describe each of the configuration sections in detail and show the full syntax that each supports.

The tags listed below and their subtags and attributes must be well-formed XML and are case-sensitive. Note that for configuration tags and attribute names, the first character is lowercase and the first character of subsequent concatenated words, if any, is uppercase. For attribute values that are members of an enumeration, the first character is uppercase and the first character of subsequent concatenated words, if any, is uppercase. Exceptions are true and false, which are always lowercase.

Configuration Section	Description
<anonymousIdentification>	Configures anonymous identification for application authorization. This is required to identify entities that are not authenticated when authorization is required.
<appSettings>	Configures custom settings for an application. This section can be declared at the machine, site, application, and subdirectory levels
<authentication>	Configures ASP.NET authentication support.
<authorization>	Configures ASP.NET authorization support.
<browserCaps>	Configures the settings for the browser capabilities component.
<caching>	Configures the cache settings for a Web application.
<clientTarget>	Adds aliases for specific user agents to an internal collection of user agent aliases.
<compilation>	Contains all the compilation settings used by ASP.NET.
<configSections>	Specifies configuration section and namespace declarations.
<configuration>	The required root element in every configuration file that is used by the common language runtime and the .NET Framework applications.
<connectionStrings>	Specifies a collection of database connection strings, as name/value pairs, for ASP.NET applications and features.
<customErrors>	Defines custom error messages for an ASP.NET application.
<deployment>	Defines configuration settings that are used to support the deployment of a Web application.
<deviceFilters>	Specifies a device or a device class in the ASP.NET MobileCapabilities system based on the user agent or browser.
<globalization>	Configures the globalization settings of an application.
<healthMonitoring>	Configures an application for health monitoring.
<hostingEnvironment>	Defines configuration settings that control the behavior of the application hosting environment.
<httpCookies>	Configures properties for cookies used by a Web application.
<httpHandlers>	Maps incoming URL requests to IHttpHandler classes.
<httpModules>	Adds, removes, or clears HTTP modules within an application.
<httpRuntime>	Configures ASP.NET HTTP runtime settings. This section can be declared at the machine, site, application, and subdirectory level.
<identity>	Controls the application identity of the Web application.
<location>	Specifies the resource that child configuration settings apply to and locks configuration settings, preventing the settings from being overridden by child configuration files.
<machineKey>	Configures keys to use for encryption and decryption of forms authentication cookie data. This section allows developers to configure a validation key that performs message authentication checks on view state data and forms authentication tickets. It can be declared at the machine, site, and application levels, but not at the subdirectory level.
<membership>	Configures parameters for managing and authenticating user accounts by using ASP.NET membership.
<mobileControls>	Defines adapter sets that map ASP.NET mobile controls to corresponding adapters within the system.web section of a Web.config configuration file.
<pages>	Identifies page-specific configuration settings.
<processModel>	Configures the ASP.NET process model settings on Internet Information Services ( IIS ) Web server systems.
<profile>	Configures parameters for managing user profile values by using the ASP.NET profile.
<roleManager>	Configures an application for role management.
<securityPolicy>	Defines valid mappings of named security levels to policy files. This section can be declared at the machine, site, and application levels.
<sessionPageState>	Configures page view-state settings for an ASP.NET application.
<sessionState>	Configures the session state HttpModule.
<siteMap>	Defines configuration settings to support the navigation infrastructure for configuring, storing, and rendering site navigation.
<trace>	Configures the ASP.NET trace service.
<trust>	Configures the code access security permission set used to run a particular application. This section can be declared at the machine, site, and application levels.
<urlMappings>	Defines a mapping that hides the real URL and maps it to a more user-friendly URL.
<webControls>
<webParts>	Allows you to specify a Web Parts personalization provider, set personalization authorizations, and add custom classes that extend the WebPartTransformer class for use by Web Parts connections.
<webServices>	Controls the settings of ASP.NET Web Services.
<xhtmlConformance>	Configures XHTML 1.0-conforming control rendering.

 

Format of ASP.NET Configuration Files

ASP.NET configuration settings are stored in Extensible Markup Language ( XML ) files.

Basically, there are two types of configuration files for ASP.NET applications you should be concerned with: Machine.config and Web.config.

The Machine.config file contains configuration information that apply to all .NET applications for a specific version of the framework installed on the machine, whereas a Web.config file contains configuration settings that apply to a specific ASP.NET application or resource ( typically a directory or a file ).

NOTE: Web.config files are optional, but the Machine.config file is required.

Configuration Basics

ASP.NET configuration files are made up of configuration sections, which in turn are made up of XML configuration elements with attributes that specify the actual configuration settings.

Essentially, each configuration section serves to implement configuration settings for a specific application need, such as for managing security, database connections, caching, compiler options, custom errors, debug and trace options, and so on.

Technically, each section declaration in a configuration file specifies:

1.               the name of a configuration settings section, and

2.               the name of the section-handler class that processes configuration data for that section.

The .NET Framework installs with predefined configuration sections in the Machine.config file. These built-in sections provide the default configuration settings and almost all the functionalities needed to configure most ASP.NET applications.

Depending on the application's need, developers can either use the default settings, or specify settings for any or all of the configuration sections in any of the application's Web.config files.

Developers can also create custom configuration sections. For more information, see Creating New Configuration Sections.

Because ASP.NET configuration files are XML-based, the elements and attributes are case-sensitive, as prescribed in the following norms:

·                  Element and attribute names are camelCased, which means that the first character of an element name is lowercase and the first letter of any subsequent concatenated word is uppercase.

·                  Attribute values are PascalCase, which means that the first character is uppercase and the first letter of any subsequent concatenated words is uppercase. Exceptions are true and false, which are always lowercase.

Configuration File Structure

All configuration information must be contained between the opening and closing tags of a <configuration> element.

Basically, the information contained within the <configuration> element is grouped into two main parts:

·                  the section declarations part, and

·                  the section settings part.

<configuration>

   <!-- section declarations -->

   <!-- section settings -->

</configuration>

In essence, a section must first be declared before you can specify configuration settings for that section. ASP.NET throws an exception if configuration settings are specified for an unknown section.

Configuration Section Declarations

Configuration section declarations appear at the top of the configuration file and must be contained between the opening and closing tags of a <configSections> element.

<configuration>

   <configSections>

      <!-- section declarations -->

   </configSections>

   <!-- section settings -->

</configuration>

Each section in turn is declared via a <section> element.

To help organize the configuration information, the section declarations are typically nested within <sectionGroup> elements, which basically represent the namespace to which the configuration settings apply.

For instance, all of the default ASP.NET configuration sections predefined in the Machine.config file are declared within the <system.web> section group.

Below shows the declaration for the built-in <authentication> and <authorization> sections as they appear in the machine configuration file.

<configuration>

   <configSections>

      <sectionGroup name = "system.web">

         <section name = "authentication"

            type = "System.Web.Configuration.AuthenticationSection, System.Web, Version=2.0.0.0,

               Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

            allowDefinition = "MachineToApplication" />

         <section name = "authorization"

            type = "System.Web.Configuration.AuthorizationSection, System.Web, Version=2.0.0.0,

               Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

         ... other configuration section declarations ...

      </sectionGroup>

   </configSections>

   ... default configuration settings ...

</configuration>

You need to declare a configuration section only once.

As mentioned, the default ASP.NET configuration sections are already declared at the machine level configuration file. All other configuration files for any ASP.NET application running on the same machine automatically inherit the configuration sections that are declared in the Machine.config file. You only need to declare a new section if you need to use a custom settings section.

Below shows use of the <configSections>, <sectionGroup>, and <section> elements in this application's Web.config file, which declares a custom settings section.

<configSections>

   <sectionGroup name = "system.web">

      <section name = "sourceView"

         type = "System.Configuration.NameValueSectionHandler, System,Version=1.0.3300.0, 

            Culture=neutral, PublicKeyToken=b77a5c561934e089" />

   </sectionGroup>

</configSections>

Likewise, configuration files in application subdirectories automatically inherit any custom settings section declared in parent directories.

Configuration Section Settings

The configuration section settings part follows the <configSections> part and contains the actual configuration settings.

Settings for a configuration section can only be defined for a section that has been declared in the <configSections> area.

Below shows the configuration section settings for the custom section declared in this application's Web.config file.

<configuration>

   <configSections>

      <sectionGroup name = "system.web">

         <!-- section declaration -->

         <section name = "sourceView"

            type = "System.Configuration.NameValueSectionHandler, System,Version=1.0.3300.0, 

               Culture=neutral, PublicKeyToken=b77a5c561934e089" />

      </sectionGroup>

   </configSections>

   <system.web>

      <!-- section settings -->

      <sourceView>

         <add key = "root" value = "d:\web projects\aspxtreme" />

      </sourceView>

   </system.web>

</configuration>

Configuring Settings for Predefined Sections

The following example shows the declaration for the built-in <authentication> and <authorization> sections as they appear in the machine configuration file.

<configuration>

   <configSections>

      <sectionGroup name = "system.web">

         <section name = "authentication"

            type = "System.Web.Configuration.AuthenticationSection, System.Web, Version=2.0.0.0,

               Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

            allowDefinition = "MachineToApplication" />

         <section name = "authorization"

            type = "System.Web.Configuration.AuthorizationSection, System.Web, Version=2.0.0.0,

               Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

         ... other configuration section declarations ...

      </sectionGroup>

   </configSections>

   ... default configuration settings ...

</configuration>

The following example shows how to specify application settings in a Web.config file for the built-in <authentication> and <authorization> sections. You do not need to declare these sections as they are already predefined in the Machine.config.

<configuration>

   <system.web>

      <authentication mode = "Forms">

         <forms name = "401kApp" loginUrl = "/login.aspx" />

      </authentication>

      <authorization>

         <deny users = "?" />

      </authorization>

   </system.web>

</configuration>

In brief, unless your application uses custom configuration sections, your Web.config files need only contain configuration settings.

 

ASP.NET Configuration Overview

The ASP.NET configuration system features an extensible infrastructure that enables you to define configuration settings at the time your ASP.NET applications are first deployed so that you can add or revise configuration settings at any time with minimal impact on operational Web applications and servers.

The ASP.NET configuration system provides the following benefits:

·      Configuration information is stored in XML-based text files. Any standard text editor or XML parser can be used to create and edit ASP.NET configuration files.

·      ASP.NET configuration settings for the entire Web server is defined in the root configuration file named C:\WINNT\Microsoft.NET\Framework\version\CONFIG\Machine.config.

·      Multiple configuration files, all named Web.config, can appear in multiple directories on an ASP.NET Web application server.

·      Each Web.config file applies configuration settings to its own directory and all child directories below it.

·      Configuration files in child directories can supply configuration information in addition to that inherited from parent directories, and the child directory configuration settings can override or modify settings defined in parent directories.

·      At run time, ASP.NET uses the configuration information provided by the Machine.config and all the Web.config files in a hierarchical directory structure to compute a collection of configuration settings for each unique URL resource. The resulting configuration settings are then cached for all subsequent requests to a resource.

·      ASP.NET detects changes to configuration files and automatically applies new configuration settings to Web resources affected by the changes. The server does not have to be rebooted for the changes to take effect. Hierarchical configuration settings are automatically recalculated and recached whenever a configuration file in the hierarchy is changed.

·      The ASP.NET configuration system is extensible. You can define new configuration parameters and write configuration section handlers to process them.

·      ASP.NET protects configuration files from outside access by configuring Internet Information Services ( IIS ) to prevent direct browser access to configuration files. HTTP access error 403 ( forbidden ) is returned to any browser attempting to directly request a configuration file.

 

Optimize and maintain your PCs with these simple tips

Author: Guest Contributor

Everyone knows that the key to keeping equipment in peak condition — whether it’s a chain saw, a motorcycle, or a desktop PC — is to follow a preemptive maintenance routine. The question is, what sort of maintenance tasks are required? In a shop full of hundreds (or thousands) of PCs, a systematic approach is essential. This list offers basic measures to incorporate into your optimization and maintenance routine.


Regularly run Defrag and the Disk Cleanup Tool on client systems

Disk fragmentation, especially on intensively used systems, will degrade performance over time. Just be careful about running disk defragmentation when large files are open. For example, if a transactional database (SQL or MSDE) is running, defragmentation tools can’t exclusively access all or parts of these types of files to defrag the disk. If there is a service that you can stop to bring this part of the system to a zero-transaction state, you will be able to defrag the drive much more effectively. This is a good task to automate by using a third-party tool like DisKeeper.

Running Disk Cleanup can optimize systems by emptying the Recycle Bin and deleting Temporary Setup Files, Downloaded Program Files, Temporary Internet Files, Old Chkdsk Files, Temporary Files, Temporary Offline Files, Offline Files, etc. To ensure regular execution, you can run the tool as a scheduled task.

Keep firmware and drivers up to date

Firmware updates can keep systems and subsystems current for the best performance. (Be sure to test the functionality before deploying firmware updates and keep a revision of the firmware distributions you’re using or have previously used; you may need that archived version again.)

Driver updates can also optimize performance. Keep a revision of the driver versions you use/have used. As with firmware, you may need an archived version in the future. (See “10 Things You Should Know about Device Driver Rollback in Windows XP” for some helpful pointers.)

Keep Windows and essential applications up to date

Use Windows Update to pull down the updates (cautiously) or use Windows Server Update Services to retrieve your approved list. Be aware of potential conflicts with service packs and updates. If PCs have other critical applications running (IIS, SQL, MSDE, etc.), apply the appropriate service packs as they become available. For Microsoft applications, check the Baseline Security Analyzer to determine service pack levels.

Keep antivirus and anti-spyware definitions up to date

Consider using automatic updates to pull down the latest definitions for your programs. Use tools like Ad-Aware by Lavasoft for extra protection against Trojans, browser hijacking, and other malicious activities.

Inspect Services configuration and Device Manager

Open the Services applet of the Windows Control Panel to verify that the Windows-based services that are running and set to Automatic at Startup are consistent with your configuration. (For more on enabling/disabling services, see “Windows XP Services That Can Be Disabled” and “Video: Disable and Enable Windows XP Services.”)

Open the Windows Device Manager to look for any devices that are not operating correctly or that may have been removed. Subsystem components may report an error if they’re incorrectly configured or not working.

Check page file configuration

Open virtual memory configuration and make sure that the page file size and location are correct for the amount of free space on the drive and the amount of memory installed on the system.

Check power quality

If you have a UPS battery, ensure that it is satisfied with the power supplied to it. If you aren’t using one, check that the power source is a good circuit and is correctly grounded. Also make sure that surge suppression strips are in use.

Stay on top of cleaning tasks

Perform a periodic full system cleaning by taking the system apart, removing all dust, and cleaning the external and internal surfaces of the computer. (If you don’t have a cleaning solution, you can make one for external surfaces out of 1:1 rubbing alcohol and water.) Be sure to unplug the electronic components when introducing a solution and allow it to dry fully. You should also:

• Clean the keyboard and mouse. Use a dust vacuum and the alcohol/water solution to clean these dust- and dirt-collecting components.

• Run a CD-ROM cleaner. As with audio systems, CD-ROM drives can be cleaned with special kits for disc cleaning.

• Clean display devices by using a cleaner to remove fingerprints, dust, and other imperfections on the screen.

• Hit floppy drives, if you have them, with a good blast of canned air to remove dust accumulations. Use covers/panels if available to help keep dust out of the drives.

• If your systems have tape drives, run a cleaning tape through to keep the tape heads clean.

Ensure proper operating area environment

Monitor the area for acceptable temperatures (somewhere between 60 and 77 degrees Fahrenheit) and good air quality. Watch out for tobacco smoke, manufacturing environments, and paper dust. If conditions are less than favorable, you might consider an environmental enclosure.

Check inside and outside the computer for proper airflow. You don’t want a computer being used inside a box or pushed into a corner, and you don’t want to see a hard drive or other internal device incorrectly installed and blocking airflow to other components. While you’re at it, check for all necessary screws on the case and make sure that the case lid or panels are fixed down on all sides. With some systems, case panels are critical to the internal airflow for components.

Check internal and external connections

Open the system and verify that all connections feel solid and are placed correctly. Double-check any accessory cards for a snug setting and good connections.

Make sure cable tensions are appropriate. Having too much strain on a cable or connection can damage the cable, device, jack/node, or the computer. Be sure that there is plenty of slack in the cables on the device and computer ends. Excess strain may cause intermittent performance issues.