为什么安装了 .NET 4 的机器不能运行针对 .NET 4.5 的 exe 而如果它们使用相同的 CLR 版本? [英] Why a machine with .NET 4 installed on it cannot run an exe that targeted .NET 4.5 while if they use the same CLR version?

问题描述

在 公共语言运行时(CLR) Microsoft 页面，它说 .Net Framework 4 和 4.5 都使用 CLR 版本 4.

In Common Language Runtime (CLR) Microsoft page, it says that both .Net Framework 4 and 4.5 uses the CLR version 4.

但是在此页面中 (.NET Framework 版本和依赖项)它写道.Net Framework 4.5 版包括 CLR 4 的更新版本"

However in this page (.NET Framework Versions and Dependencies) it writes '.Net Framework version 4.5 Included an updated version of CLR 4'

还写道:

'针对 .NET Framework 4.5.1 的可执行文件将被阻止在仅安装了 .NET Framework 4.5 的计算机上运行，​​并且系统将提示用户安装 .NET Framework 4.5.1.此外，不应从 .NET Framework 4.5 应用程序调用 .NET Framework 4.5.1 程序集.'

问题:如果所有 Net Framework 版本 4、4.5 和 4.5.1 在相同的 CLR 版本 4 上运行托管代码，为什么我无法运行可执行文件在仅安装了 .Net 4.0 的机器上针对 .Net 框架 4.5?

QUESTION: If all Net Framework version 4 and 4.5 and 4.5.1 runs the managed code on the same CLR version that is 4, why I cannot run an executable that targeted .Net framework 4.5 on a machine that has only .Net 4.0 installed?

(无论您的目标是 .NET framework 4 还是 4.5 或 4.5.1，编译器最终都不会生成适用于 CLR 版本 4 的 IL?)

(Do not the compilers produce an IL that is for CLR version 4 in the end regardless you targeted .NET framework 4 or 4.5 or 4.5.1?)

推荐答案

是的，CLR版本是一样的，还是v4.0.30319..NET Framework 类库以一种高度向后破坏的方式被打破.通过将 WinRT(商店应用程序)支持集成到框架中而驱动的更改.几种类型从一个程序集移动到另一个程序集，最明显的是 ExtensionAttribute 和 ICommand.移动设备上对小型 .NET 实现的需求起到了重要作用.System.Core 和 PresentationFramework 不小.

Yes, the CLR version is the same, still v4.0.30319. What broke in a highly backwards-breaking way were the .NET Framework class libraries. Changes that were driven by integrating support for WinRT (Store apps) into the framework. Several types were moved from one assembly to another, the most visible ones are ExtensionAttribute and ICommand. The need for small .NET implementations on mobile devices was instrumental. System.Core and PresentationFramework are not small.

这很重要，声明类型的程序集是 .NET 类型的类型标识的一部分.或者换句话说，具有相同命名空间名称和类型名称的 .NET 类型永远不会与来自另一个程序集的具有相同全名的类型兼容.

That's rather a big deal, the assembly that a type is declared in is part of the type identity of a .NET type. Or to put it another way, a .NET type that has the same namespace name and type name is never compatible with a type with the same full name that came from another assembly.

这完全是由于 .NET 4.0 中开始的创新.从 [TypeForwardedTo] 属性开始，该属性用于移动类型.以及 c:program files eference assembly 中特制的参考程序集.特殊之处在于它们仅包含元数据，并不与您的程序将在运行时使用的 GAC 中安装的实际程序集直接匹配.

That this was possible at all was due to innovations that started in .NET 4.0. Starting with the [TypeForwardedTo] attribute which is what is used to move a type. And the specially crafted reference assemblies in c:program files eference assemblies. Special in that they only contain metadata and are not a direct match with the actual assemblies installed in the GAC that your program will use at runtime.

有时会以非常难以诊断的方式出错，这是由使用错误的参考程序集引起的.不幸的是，微软将传统的参考程序集保存在 c:windowsmicrosoft.netframework 中.使用它们的项目以非常悲惨的方式失败.

This does go wrong sometimes in a very hard to diagnose ways, induced by using the wrong reference assemblies. Unfortunately Microsoft kept the traditional reference assemblies in c:windowsmicrosoft.netframework around. Projects that use them fail in a pretty miserable way.

所以这行不通，面向 .NET 4.5 的程序将在错误的 4.0 GAC 程序集中查找诸如 ExtensionAttribute 和 ICommand 之类的类型.并以完全无法诊断的 TypeLoadException 失败.因此，首先检查 [TargetFramework] 属性，以便尽早尝试运行程序失败.

So this just can't work, a program that targets .NET 4.5 will look in the wrong 4.0 GAC assemblies for types like ExtensionAttribute and ICommand. And fail with a utterly undiagnosable TypeLoadException. Accordingly, the [TargetFramework] attribute is checked first to fail the attempt to run the program as early as possible.

这篇关于为什么安装了 .NET 4 的机器不能运行针对 .NET 4.5 的 exe 而如果它们使用相同的 CLR 版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！