The bottom line is that under your scenario, you specified .Net 4 as your only supported runtime, so your app will load with CLR 4.
The CLR behavior with your program is exactly as designed:
When I run your test app with the supportedRuntime
as v4.0, Process Explorer shows it loads mscorlib v4.0.30319.
When I run with supportedRuntime
as v2.0.50727, Process Explorer shows it loads mscorlilb v2.0.50727.
When I run with no supportedRuntime
element, Process Explorer shows it loads mscorlilb v2.0.50727.
This blurb from Microsoft states that the supportedRuntime
element defines the specific version on which your program runs:
By default, an application runs on the version of the .NET Framework that it was built for. If that version is not present and the application configuration file does not define supported versions, a .NET Framework initialization error may occur. In this case, the attempt to run the application will fail.
To define the specific versions on which your application runs, add one or more elements to your application's configuration file. Each element lists a supported version of the runtime, with the first specifying the most preferred version and the last specifying the least preferred version.
There are two separate elements at play, here. Only the supportedRuntime
element applies to your scenario.
The supportedRuntime
element defines the CLR versions on which your app will run, in the preferred order. If you list supported runtimes, then those CLR versions will be used, going down the list from top to bottom until an installed CLR version is found. If you don't list support runtimes, then your program will run with the version of the CLR against which it was compiled.
The useLegacyV2RuntimeActivationPolicy
element applies only to mixed-mode assemblies --- programs or DLLs that contain managed (.Net) and unmanaged (native) code. Your sample program isn't a mixed-mode assembly. For mixed-mode assemblies, setting the value to false
(the default), or not setting it all, uses the new .Net 4 in-process side-by-side loading for mixed-mode assemblies, so your app can run with CLR 4, and load a mixed-mode assembly in the same process using CLR 1.0-2.0. Setting it to true
essentially reverts to the previous functionality prior to .Net 4, where the in-process side-by-side functionality is disabled, and whatever CLR version is selected to run the app will attempt to load your mixed-mode assembly. The CLR version used to load the mixed-mode assembly will be whichever one is selected to run the app, based on which version was used to compile the app, and your listed supported runtimes, if any.
There's an MSDN Magazine article and an MSDN article about .Net 4 loading and In-Process Side-by-Side (In-Proc SxS) execution for COM components, which also has an impact on your scenario without COM components. Prior to .Net 4, if you compiled your app with a version of the CLR, and that version wasn't available on the system at runtime, the app would automatically run on a newer version of the CLR if it was installed. As of .Net 4, apps now won't run with a newer version of the CLR unless you specify the newer version in the supportedRuntimes
element.
Here's a quote from the MSDN article:
Application developers. Side-by-side hosting has almost no effect on application developers. By default, applications always run against the version of the .NET Framework they were built on; this has not changed. However, developers can override this behavior and direct the application to run under a newer version of the .NET Framework (see scenario 2).
Library developers and consumers. Side-by-side hosting does not solve the compatibility problems that library developers face. A library that is directly loaded by an application -- either through a direct reference or through an Assembly.Load call -- continues to use the runtime of the AppDomain it is loaded into. You should test your libraries against all versions of the .NET Framework that you want to support. If an application is compiled using the .NET Framework 4 runtime but includes a library that was built using an earlier runtime, that library will use the .NET Framework 4 runtime as well. However, if you have an application that was built using an earlier runtime and a library that was built using the .NET Framework 4, you must force your application to also use the .NET Framework 4 (see scenario 3).
Finally, if you're on Vista, Win7, Server 2008, Server 2008 R2, you automatically have CLR 2.0 installed. Therefore, if you were to remove your supportedRuntimes
element, or change it to v2.0.50727, you might still have CLR 2.0 available as a runtime.