The Microsoft .NET Framework includes support for configuring applications by using XML configuration files; this appendix demonstrates how to make use of these.
An application configuration file is stored in the same directory as the application it relates to. The file name is the name of the application with a .config extension. For example, an application named MyApplication.exe would have a configuration file named MyApplication.exe.config. For multifile assemblies, the configuration file should be named after the file that contains the manifest.
When an application requests configuration information, the common language runtime (CLR) tries to satisfy the request from the global machine configuration file before the application file; that is to say that the machine configuration file overrides the application file. This approach allows machine administrators to redefine the settings for an application after it has been installed; this should not be done lightly and can result in unexpected application behavior. The machine configuration file is named Machine.config and can be found in the Config subdirectory of the .NET Framework installation.
The CLR ensures that configuration files are loaded automatically; thus, no action is required by the programmer. Configuration files must contain the root XML node <configuration>, as shown here:
<configuration>
<!-- configuration statements -->
</configuration>The following sections detail the uses of application configuration files.
Applications that require a specific version of the CLR can use the <startup><requiredruntime> declaration, as shown in the following example:
<configuration>
<startup>
<requiredRuntime version="v1.0.3706.000" safemode="false"/>
</startup>
</configuration>An application with this configuration file requires version 1.0.3706.000 of the CLR to operate properly. The safemode attribute specifies whether the application will accept versions that might be compatible; setting the attribute to true ensures that only the specified version will be used, while the value false indicates that a suitable substitute can be used. Substitutes are required to have the same major and minor versions (in this case, 1 and 0) but can have different build and revision versions (3706 and 000 respectively); the expectation is that releases with similar version numbers are likely to be interchangeable.
By default, the CLR assigns a separate thread for the garbage collector (GC); this is known as concurrent garbage collection because the GC thread runs alongside application threads. Applications that are heavily multithreaded can gain performance benefits from disabling GC concurrency, as shown here:
<configuration>
<runtime>
<gcConcurrent enabled="false"/>
</runtime>
</configuration>The enabled attribute specifies whether the GC should operate concurrently. The advantage of GC concurrency is that user interfaces tend to be more responsive and won’t freeze during a collection run.
Disabling GC concurrency causes memory management to be performed using the same threads that execute the application code. The application will be less responsive, but the performance of GC tasks is greatly increased. Server-side applications typically benefit from disabling GC concurrency.
More Info
For more information about garbage collection, consult Appendix D.
Application configuration files can be used to manage assemblies. See Appendix B, for more details.
Objects can be registered with the .NET remoting system with configuration files. See Chapter 15, for details.