12

在Common Language Runtime (CLR) Microsoft 页面中，它表示 .Net Framework 4 和 4.5 都使用 CLR 版本 4。

但是，在此页面（.NET Framework 版本和依赖项）中，它写道“.Net Framework 4.5 版包含 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 Framework 4.5 的可执行文件？

（不管您的目标是 .NET 框架 4、4.5 还是 4.5.1，编译器最终不会生成适用于 CLR 版本 4 的 IL 吗？）

4

2 回答 2

18

是的，CLR版本是一样的，还是v4.0.30319。.NET Framework 类库以一种高度向后突破的方式发生了变化。通过将 WinRT（应用商店应用）支持集成到框架中所驱动的更改。几种类型从一个程序集移动到另一个程序集，最明显的是 ExtensionAttribute 和 ICommand。在移动设备上实现小型 .NET 的需求非常重要。System.Core 和 PresentationFramework 都不小。

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

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

由于使用错误的参考程序集，这有时会以非常难以诊断的方式出错。不幸的是，微软将传统的参考程序集保留在 c:\windows\microsoft.net\framework 中。使用它们的项目以非常悲惨的方式失败。

所以这根本行不通，针对 .NET 4.5 的程序将在错误的 4.0 GAC 程序集中查找 ExtensionAttribute 和 ICommand 等类型。并以完全无法诊断的 TypeLoadException 失败。因此，首先检查 [TargetFramework] 属性以尽可能早地尝试运行程序失败。

于 2014-03-12T13:35:00.723 回答
1

通过微软，

每个程序集，无论是静态的还是动态的，都包含一组数据，这些数据描述了程序集中的元素如何相互关联。程序集清单包含此程序集元数据。 大会清单。 此清单包含有关该可执行文件的构建 CLR 的信息，并且在执行 exe/dll .net CLR 时会尝试找出相同的 CLR 版本。请参阅图像， 由 v 3.5 构建 由 v 3.5 由 4.0 构建 构建和由 4.0 构建。

于 2014-03-12T13:00:12.377 回答