Export (0) Print
Expand All

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.

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 ASP.NET Configuration File Structure (Sections and Section Handlers).

Because they are plaintext XML files, you can create or edit configuration settings in the following ways:

Case-Sensitivity

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.

Custom Sections

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 How to: Create Custom Configuration Sections Using ConfigurationSection.

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, see Editing ASP.NET Remote Configuration Files and How to: Access and Modify ASP.NET Configuration Files Remotely.

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 General Attributes Inherited by Section Elements.

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 Managing Changes to Configuration Settings.

Community Additions

ADD
Show:
© 2014 Microsoft