.net 将VS11 Beta升级到VS2012 RC后，在app.config中支持运行时v4.0

从VS11 Beta版升级到VS2012 RC版后，我将目标从.NET 4.0修改为.NET 4.5版。我注意到app.config下面的部分

<startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

上面的是什么

---

当我试图从VS2012 RC中创建一个新项目（而不是升级现有项目）时，我在app.config中没有看到上面的部分，这是永恒的.NET版本控制困境的副作用。NET 4.5不是.NET framework的并行版本，它完全取代了.NET 4.0安装。就像3.0和3.5取代了.NET2.0安装一样

3.0和3.5的更新相当温和，框架刚刚获得了一堆新的程序集。CLR和核心基类程序集没有更改。很多

框架4.5版本中包含的clr.dll文件仍然具有4.0.30319版本号。与CLR的4.0版本相同的版本号。并且在执行针对.NET 4.0框架的.NET应用程序时没有问题

---

不过，该框架版本在内部进行了大量修改。它获得了语言投影，可以用托管语言编写在Windows 8上运行的Metro应用程序。重大更改包括将类从一个程序集移动到另一个程序集，从而允许在电话或板岩上进行适度的部署。添加到项目中的app.exe.config文件可确保用户具有所需的版本。部署.config文件是可选的，但是当用户只安装了.NET4.0时，会看到一条非常不透明的异常消息。实际上不确定那是什么样子。当他没有4.5版本时触发的自动安装可能也不起作用。

尽管Hans Passant所说的一切都是正确的，但他忽略了一个关键点，那就是PE头在这次崩溃中的作用

由于Dotnet 4.5是在Dotnet 4.0之上进行的就地安装，并且由于它不更新Dotnet版本号，因此使用Dotnet 4.5构建的二进制文件在其二进制文件的PE头（4.0.30319）中具有旧的Dotnet 4.0版本号

因为CLR在PE头中使用此值来确定加载哪个版本的Dotnet Framework，而且对于根据Dotnet 4.5构建的程序集，此值不会更改，然后，在没有任何附加信息的情况下，CLR无法知道PE头中包含4.0.30319的程序集是否需要链接到Dotnet 4.0或4.5

app.config中的supportedRuntime元素为CLR提供了额外的信息。因此，如果您在仅安装了Dotnet 4.0的系统上启动Dotnet 4.5应用程序，并且存在supportedRuntime条目，则CLR将弹出一条有用的消息，通知您未安装所需的Dotnet版本。然而，如果在仅安装了Dotnet 4.0的系统上启动相同的Dotnet 4.5应用程序，但没有supportedRuntime条目，则该应用程序可能会开始运行，但在以后尝试使用Dotnet 4.5功能时会崩溃

---

虽然使用VS2012 RC和针对Dotnet 4.5构建的项目可能缺少supportedRuntime条目，但使用VS2012 RTM构建的项目确实有该条目。

因此，当用户拥有.NET 4.0时，它将显示错误，说明该配置需要.NET 4.5。如果那个配置不存在呢？既然我以.NET4.5为目标，那么这不会也会带来错误吗？是的，但这一点很难解释。像MissingMethodException或FileNotFoundException，不是一条友好的消息，比如“你没有.NET 4.5，你想让我为你安装吗？”见@nobugz，我总是有点困惑，我需要在我的应用程序中提供哪个版本的.NET。根据您上面的评论，我是否理解针对.NET 4.5的应用程序只需提供.NET 4.5？换句话说，我不必担心系统上是否有.NET 3.5、3.0等版本？您将收到一条配置错误消息：

Web.config文件元素中的“targetFramework”属性仅用于针对.NET Framework的4.0及更高版本（例如“”）。“targetFramework”属性当前引用的版本高于.NET Framework的已安装版本。指定有效的.NET Framework目标版本，或安装所需的.NET Framework版本。