|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Editing ASP.NET Configuration Files
ASP.NET configuration data is stored in XML text files, each named Web.config. Web.config files can appear in multiple directories in ASP.NET applications. Each Web.config file applies configuration settings to its own directory and to all the child directories below it. Settings in child directories can optionally override or modify settings that are specified in parent directories. The root of the ASP.NET configuration hierarchy is the systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\Web.config file, which includes settings that apply to all ASP.NET applications that run a specific version of the Microsoft .NET Framework. Because each ASP.NET application inherits default configuration settings from the root Web.config file, you only need to create Web.config files for settings that override the default settings.
Configuration File Structure
Each configuration file contains nested XML tags and subtags with attributes that specify the configuration settings. All configuration information resides between the <configuration> and </configuration> root XML tags. Configuration information between these tags is grouped into two main areas: the configuration section-handler declaration area and the configuration section settings area. For more information, see.
Editing Configuration Settings
Because they are plaintext XML files, you can create or edit configuration settings in the following ways:
By using the ASP.NET configuration API. For more information, see.
By using the ASP.NET MMC snap-in. For more information, see.
By using the Web Site Administration Tool for Web sites and ASP.NET applications. For more information, see.
By using a text editor or an XML editor to directly edit the configuration files. For proper syntax, see the configuration reference topics inand .
Because tags must be well-formed XML, the tags, subtags, and attributes are case-sensitive. Tag names and attribute names are camel-cased, which means that the first character of a tag name is lowercase and the first letter of any subsequent concatenated word or words is uppercase. In most cases, string attribute values are Pascal-case, which means that the first character is uppercase and the first letter of any subsequent concatenated word or words is uppercase. Exceptions are true and false, which are always lowercase.
The ASP.NET configuration infrastructure makes no assumptions about the types of configuration data that the infrastructure supports. Configuration section-handler classes process all Web.config data. You can use the predefined configuration section handlers that are supplied with the .NET Framework, or you can create your own handlers to process custom configuration data.
For more information about creating custom configuration types, see Creating New Configuration Sections.
Editing Remote Configuration Files
The ASP.NET configuration API allows your application to modify the configuration files on a remote computer. In particular, you can modify the Machine.config or a Web.config file in any Microsoft Internet Information Services (IIS) application, or its child directories on a remote computer. If the Web.config file does not exist, the returned configuration data consists entirely of inherited settings that apply to the specified path. If your application requests an update on this returned configuration data, a new file is created. For more information, seeand .
Configuration Changes Cause a Restart of the Application Domain
Changes to configuration settings in Web.config files indirectly cause the application domain to restart. This behavior occurs by design. You can optionally use the configSource attribute to reference external configuration files that do not cause a restart when a change is made. For more information, see configSource in.
Attempts to change a configuration file by someone who does not have permission to edit the file will not cause a restart of the application domain.
For more information, see.