Configuring Apps by using Configuration Files
The .NET Framework, through configuration files, gives developers and administrators control and flexibility over the way applications run. Configuration files are XML files that can be changed as needed. An administrator can control which protected resources an application can access, which versions of assemblies an application will use, and where remote applications and objects are located. Developers can put settings in configuration files, eliminating the need to recompile an application every time a setting changes. This section describes what can be configured and why configuring an application might be useful.
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 would be written as <runtime/> or <runtime></runtime>.
As with all XML files, the syntax in configuration files is case-sensitive.
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="188.8.131.52" href="http://www.litwareinc.com/myAssembly.dll"/>
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.
An application configuration file contains settings that are specific to an app. This file includes configuration settings that the common language runtime reads (such as assembly binding policy, remoting objects, and so on), and settings that the app can read.
The name and location of the application configuration file depend on the app's host, which can be one of the following:
These apps have two configuration files: a source configuration file, which is modified by the developer during development, and an output file that is distributed with the app.
When you develop in Visual Studio, place the source configuration file for your app in the project directory and set its Copy To Output Directory property to Copy always or Copy if newer. The name of the configuration file is the name of the app with a .config extension. For example, an app called myApp.exe should have a source configuration file called myApp.exe.config.
Visual Studio automatically copies the source configuration file to the directory where the compiled assembly is placed to create the output configuration file, which is deployed with the app. In some cases, Visual Studio may modify the output configuration file; for more information, see the Redirecting assembly versions at the app level section of the Redirecting Assembly Versions article.
For more information about ASP.NET configuration files, see ASP.NET Configuration Settings
Internet Explorer-hosted app.
If an app 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 app base. The configuration file must be located on the same website as the app.
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