为什么安装了.NET 4的计算机在使用相同的.NET版本时不能运行以.NET 4.5为目标的exe？
在公共语言运行时(CLR)微软页面中，.Net Framework4和4.5都使用CLR 4。
然而，在这个页面(.NET框架版本和依赖项)中，它写的'.Net框架版本4.5包括一个更新版本的CLR 4‘
还写道：
针对.NET Framework4.5.1的可执行文件将被阻止在只安装了.NET Framework4.5的计算机上运行，用户将被提示安装.NET Framework4.5.1。此外，不应该从.NET Framework4.4.5应用程序调用.NET Framework4.5.1程序集。
问题：如果所有4、4.5和4.5.1都在同一个CLR版本(即4)上运行托管代码，为什么i不能在只安装了.Net 4.0的机器上运行针对.Net Framework4.5的可执行文件？
(编译器最终不是为CLR 4生成IL吗，而不管您的目标是.NET框架4、4.5或4.5.1?)
回答 2
Stack Overflow用户
发布于 2014-03-12 13:35:00
是的，CLR版本是一样的，仍然是4.0.30319。.NET框架类库以一种极强的反向破坏的方式进行了突破。通过将对WinRT (存储应用程序)的支持集成到框架中来驱动的更改。几种类型从一个程序集移动到另一个程序集，最明显的类型是ExtensionAttribute和ICommand。对于移动设备上小型.NET实现的需求是非常重要的。System.Core和PresentationFramework并不小。
这很重要，在其中声明类型的程序集是.NET类型类型标识的一部分。换句话说，具有相同名称空间名称和类型名称的.NET类型永远不会与来自另一个程序集的具有相同全名的类型兼容。
这完全是由于在.NET 4.0中开始的创新。从TypeForwardedTo属性开始，它是用来移动类型的。以及c:\program \ reference程序集中巧尽心思构建的引用程序集。特殊之处在于，它们只包含元数据，而不是与程序在运行时将使用的GAC中安装的实际程序集直接匹配。
有时候，由于使用错误的引用程序集，这会导致很难诊断的错误。不幸的是，微软在c:\windows\microsoft.net\framework中保留了传统的引用程序集。使用它们的项目以一种非常糟糕的方式失败。
因此，这是无法工作的，一个以.NET 4.5为目标的程序会在错误的4.0GAC程序集中查找ExtensionAttribute和ICommand这样的类型。并以一个完全不可诊断的TypeLoadException失败。因此，首先检查TargetFramework属性，以使尽早运行程序的尝试失败。
Stack Overflow用户
发布于 2014-03-12 13:00:12
微软公司，
每个程序集，无论是静态的还是动态的，都包含一组数据，这些数据描述程序集中的元素是如何相互关联的。程序集清单包含此程序集元数据。大会宣言。此清单包含有关该可执行文件的生成CLR的信息，并且在执行exe/dll时，.net CLR尝试查找相同的CLR版本。看照片，
按V 3.5和
增加4.0。
https://stackoverflow.com/questions/22351798
复制相似问题
腾讯云开发者
