Before _CorExeMain starts the runtime, it searches for an application configuration file. Certain settings in this file can influence which version of the CLR is used and how the CLR is initialized. In the configuration file shown here, you can see the different configuration options:
<!-- yourapp.exe.config --> <configuration> <startup>
<!-- if your app works with a later version of the CLR, add an entry here --> </startup>
<gcServer enabled="false"/> <!-- set this to true to optimize GC for throughput instead of responsiveness -- >
<legacyNullReferenceExceptionPolicy enabled="false"/> <!-- set to "true" if you want the Win32 exception 0xC0000005 to be mapped to System::NullReferenceException (like in 1.1).--> <!-- set to "false" if you want 0xC0000005 to be mapped to System::AccessViolationException (default in 2.0) -->
<legacyImpersonationPolicy enabled="false"/> <!-- set this to true if WindowsIdentity should not flow across asynchronous points -- >
<legacyV1CASPolicy enabled="false"/> <!-- set to true to avoid support for unrestricted identity permissions -- >
C++/CLI applications can only execute with CLR version 2.0 or higher. Therefore, configuring a supported or a required runtime version will make sense when the next version of the CLR is released. Other configurations can influence how the GC works and whether the CLR provides backward compatibility with older CLR versions. The .NET Framework SDK documentation contains a reference of the configuration file schema, including descriptions of the elements used in this sample configuration file. For now, it is sufficient to know that an application configuration file can configure the chosen runtime version and certain aspects of CLR's behavior.
Was this article helpful?