当执行对.NET 4.0的应用程序，在.NET 2.0遵守 [英] When executing an application on .net 4.0, complied under .net 2.0

问题描述

假设：

1. 在C＃源$ C ​​$ C以下是.NET 2.0（CLR 2.0）下编制的;和
2. 在上面的应用程序使用的app.config 下面列出;和
3. 只有.NET 4.0（CLR 4.0）被安装在客户机的执行应用程序的环境，

随后.NET版本在内部加载执行客户端的环境中的应用？

说明

下面的控制台应用程序将简单地显示，其CLR版本是 v4.0.30319 在控制台中，但堆栈的@Reed科普塞的回答（的 CLR 2.0 VS 4.0效果）显示，.NET 2.0在这种情况下，被加载。此外，在 MSDN 该说的时候 useLegacyV2RuntimeActivati​​onPolicy 设置为false 假：

  

使用默认的激活策略为.NET Framework 4和更高版本，   这是为了让传统的运行时激活技术来加载CLR   版本1.1或2.0到流程。

这听起来像.NET 2.0，尽管的app.config 有一个.NET 4.0配置的加载。难道我误解了什么？

来源

C＃源$ C ​​$ C

 命名空间ConsoleApplication1
{
    类节目
    {
        静态无效的主要（字串[] args）
        {
            字符串版本= Environment.Version.ToString（）;
            Console.WriteLine（版本）;
        }
    }
}
 

的app.config

 ＆LT; XML版本=1.0＆GT？;
＆lt;结构＆GT;
    ＆LT;启动useLegacyV2RuntimeActivati​​onPolicy =假＆GT;
        ＆LT; supportedRuntime版本=v4.0.30319/＆GT;
    ＆LT; /启动＆GT;
＆LT; /结构＆gt;
 

解决方案

底线是，根据您的情况，您指定了.NET 4作为唯一支持的运行时，使您的应用程序将加载CLR 4

与你的程序的CLR的行为是完全一样的设计：

当我运行你的测试程序的 supportedRuntime 为V4.0，进程资源管理器显示它加载的mscorlib v4.0.30319。

当我与 supportedRuntime 作为V2.0.50727运行，进程资源管理器显示它加载mscorlilb V2.0.50727。

当我没有 supportedRuntime 元素中运行，进程资源管理器显示它加载mscorlilb V2.0.50727。

这Blurb的微软指出， supportedRuntime 元素定义你的程序在其上运行的特定版本：

  

默认情况下，它是专为.NET框架版本的应用程序运行。如果该版本不是present和应用程序配置文件没有定义支持的版本，可能会出现一个.NET框架初始化错误。在这种情况下，运行该应用程序的尝试将失败。

     

要定义的特定版本在其上运行应用程序，添加一个或多个元素到应用程序的配置文件。每个元素列出了运行时的受支持版本，与第一指定最preferred版本，最后指定至少preferred版本。

---

有在作怪两个独立的元素，在这里。只有 supportedRuntime 元素适用于您的方案。

在 supportedRuntime 元素定义了CLR版本上，你的应​​用程序将运行在preferred订单。如果列出支持的运行时间，那么这些CLR版本将被使用，下降从上到下列表，直到某安装CLR版本中找到。如果你没有列出支持的运行时间，那么你的程序将与CLR反对它被编译的版本上运行。

在 useLegacyV2RuntimeActivati​​onPolicy 元素只适用于混合模式组件---程序或DLL包含托管（.NET）和非托管（本地）code。示例程序不是一个混合模式的组装。对于混合模式的组件，其值设置为假（默认值），或不设置这一切，使用新的.NET 4的进程并排侧装混合模式组件，让你的应用程序可以使用CLR 4上运行，并使用CLR 1.0-2.0在同一进程中加载​​混合模式的组装。将其设置为真基本恢复到之前的previous功能.NET 4，在进程内并排端功能被禁用，任何CLR版本选择要运行的应用程序将尝试加载混合模式的组装。在CLR版本用来加载混合模式的组装将选择哪一个运行应用程序，在此基础上的版本是用来编译应用程序，你上市支持运行时，如果有的话。

---

这里有一个 MSDN杂志文章和的有关.NET 4加载和过程中边并排（进程内的SxS）执行COM组件，其中也有MSDN文章您的方案产生影响，而不COM组件。此前.NET 4，如果你编译你的应用程序有一个版本的CLR，而且该版本是无法在系统上运行时，应用程序将在CLR的较新版本会自动运行，如果它被安装。作为.NET 4中的程序，应用现在不会与CLR的较新版本上运行，除非你指定的 supportedRuntimes 元素的新版本。

下面是来自MSDN文章报价：

  

应用程序开发人员。侧由端主机对应用程序开发者几乎没有影响。默认情况下，应用程序始终对.NET框架，他们建的版本上运行;这并没有改变。但是，开发人员可以重写此行为，并指示应用程序在.NET Framework的新版本上运行（参见方案2）。

     

图书馆开发者和消费者。侧并排托管并不能解决库​​开发人员所面临的兼容性问题。既可以通过直接引用或通过的Assembly.Load呼叫 - - 即直接装载由一个应用程序库继续使用它被装入的AppDomain的运行时间。您应该测试您的图书馆对.NET Framework的要支持所有版本。如果一个应用程序被编译使用.NET Framework 4运行，但包括使用较早的运行建立了一个库，该库将使用.NET Framework 4运行时也是如此。但是，如果你有使用较早的运行时间，而且是使用.NET Framework 4建库构建的应用程序，你必须迫使你的应用程序也使用.NET Framework 4（参见方案3）。

最后，如果你是在Vista，Win7的，服务器2008，Server 2008 R2中，您自动拥有CLR 2.0安装。因此，如果你要删除你的 supportedRuntimes 元素，或将其更改为V2.0.50727，你可能仍然有CLR 2.0作为运行时。

Assuming that:

1. The C# source code below is compiled under .NET 2.0 (CLR 2.0); and
2. The above application uses the app.config listed below; and
3. Only .NET 4.0 (CLR 4.0) is installed on the environment of the client executing the application,

then which version of .NET is internally loaded to execute the application on the client's environment?

Description

The console application below will simply show that its CLR version is v4.0.30319 in the console, but @Reed Copsey's answer of the stack (CLR 2.0 vs 4.0 performance?) shows that .NET 2.0 is loaded in this case. Moreover, at MSDN it says when useLegacyV2RuntimeActivationPolicy is set to false false:

Use the default activation policy for the .NET Framework 4 and later, which is to allow legacy runtime activation techniques to load CLR version 1.1 or 2.0 into the process.

It sounds like .NET 2.0 is loaded in spite of the app.config having a .NET 4.0 configuration. Have I misunderstood anything?

Source

C# source code

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            string version = Environment.Version.ToString();
            Console.WriteLine(version);
        }
    }
}

app.config

<?xml version="1.0"?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="false">
        <supportedRuntime version="v4.0.30319"/>
    </startup>
</configuration>

解决方案

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.

这篇关于当执行对.NET 4.0的应用程序，在.NET 2.0遵守的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！