Configuration files are XML files that can be changed as needed. Developers can use configuration files to change settings without recompiling applications. Administrators can use configuration files to set policies that affect how applications run on their computers.
Managed code can use the classes in the System.Configuration namespace to read settings from the configuration files, but not to write settings to those files.
This topic describes the syntax of configuration files and provides information about the three types of configuration files: machine, application, and security.
Configuration files contain elements, which are logical data structures that set configuration information. Within a configuration file, you use tags to mark the beginning and end of an element. For example, the <runtime> element consists of <runtime>child elements</runtime>. An empty element has a start tag, but no end tag.
You specify configuration settings using predefined attributes, which are name/value pairs inside an element's start tag. The following example specifies two attributes (version and href) for the <codeBase> element, which specifies where the runtime can locate an assembly (for more information, see Specifying an Assembly's Location).
<codeBase version="126.96.36.199" href="http://www.litwareinc.com/myAssembly.dll"/>
As with all XML files, the syntax in configuration files is case-sensitive.
The machine configuration file, Machine.config, contains settings that apply to an entire computer. This file is located in the %runtime install path%\Config directory. Machine.config contains configuration settings for machine-wide assembly binding, built-in remoting channels, and ASP.NET.
The configuration system first looks in the machine configuration file for the appSettings element and other configuration sections that a developer might define. It then looks in the application configuration file. To keep the machine configuration file manageable, it is best to put these settings in the application configuration file. However, putting the settings in the machine configuration file can make your system more maintainable. For example, if you have a third-party component that both your client and server application uses, it is easier to put the settings for that component in one place. In this case, the machine configuration file is the appropriate place for the settings, so you don't have the same settings in two different files.
Deploying an application using XCOPY will not copy the settings in the machine configuration file.
For more information about how the common language runtime uses the machine configuration file for assembly binding, see How the Runtime Locates Assemblies.
Application configuration files contain settings specific to an application. This file contains configuration settings that the common language runtime reads (such as assembly binding policy, remoting objects, and so on), and settings that the application can read.
The name and location of the application configuration file depend on the application's host, which can be one of the following:
The configuration file for an application hosted by the executable host is in the same directory as the application. The name of the configuration file is the name of the application with a .config extension. For example, an application called myApp.exe can be associated with a configuration file called myApp.exe.config.
In Visual Studio projects, place the .config file in the project directory and set its Copy To Output Directory property to Copy always or Copy if newer. Visual Studio automatically copies the file to the directory where it compiles the assembly.
For more information about ASP.NET configuration files, see ASP.NET Settings Schema
Internet Explorer-hosted application.
If an application hosted in Internet Explorer has a configuration file, the location of this file is specified in a <link> tag with the following syntax:
<link rel="ConfigurationFileName" href="location">
In this tag, location is a URL to the configuration file. This sets the application base. The configuration file must be located on the same Web site as the application.
Security configuration files contain information about the code group hierarchy and permission sets associated with a policy level. We strongly recommend that you use the Code Access Security Policy tool (Caspol.exe) to modify security policy to ensure that policy changes do not corrupt the security configuration files.
Starting with the .NET Framework 4, the security configuration files are present only if security policy has been changed.
The security configuration files are in the following locations:
Enterprise policy configuration file: %runtime-install-path%\Config\Enterprisesec.config
Machine policy configuration file: %runtime-install-path%\Config\Security.config
User policy configuration file: %USERPROFILE%\Application data\Microsoft\CLR security config\vxx.xx\Security.config