VS11BetaからVS2012RCにアップグレードした後、.NET4.0から.NET4.5をターゲットに変更しました。次のセクションのapp.configに気づきました
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
上記は何のためですか？
VS2012 RC内から（既存のプロジェクトのアップグレードではなく）新しいプロジェクトを作成しようとすると、app.configに上記のセクションが表示されません。
これは、永遠の.NETバージョン管理の泥沼の副作用です。.NET 4.5は、.NET Frameworkのサイドバイサイドバージョンではなく、.NET4.0インストールを完全に置き換えます。3.0および3.5が.NET2.0インストールに取って代わったように。
3.0と3.5のアップデートはかなり穏やかで、フレームワークはたくさんの新しいアセンブリを取得したばかりです。CLRとコア基本クラスアセンブリは変更されていません。多くの。
フレームワークの4.5バージョンに含まれているclr.dllファイルには、まだ4.0.30319バージョン番号が付いています。CLRの4.0バージョンと同じバージョン番号。また、.NET4.0フレームワークを対象とする.NETアプリの実行に問題はありません。
ただし、そのフレームワークバージョンは内部で大幅に変更されました。これは、Windows8で実行されるMetroアプリを管理された言語で記述できるようにする言語プロジェクションを取得しました。大幅な変更には、あるアセンブリから別のアセンブリへのクラスの移動が含まれ、電話またはスレートへの展開を控えめにすることができます。プロジェクトに追加されたapp.exe.configファイルは、ユーザーがその必要なバージョンを持っていることを保証します。.configファイルの展開はオプションですが、.NET 4.0のみがインストールされている場合、ユーザーにはかなり不透明な例外メッセージが表示されます。それがどのように見えるかは実際にはわかりません。彼が4.5を持っていないときにトリガーされる自動インストールもおそらく機能しません。
Hans Passantはすべてにおいて正しいが、この大失敗におけるPEヘッダーの役割である重要なポイントを見逃していると彼は言う。
Dotnet4.5はDotnet4.0の上にインプレースインストールされ、Dotnetバージョン番号を更新しないため、Dotnet 4.5を使用して構築されたバイナリでは、バイナリのPEヘッダーに古いDotnet 4.0バージョン番号が含まれます（ 4.0.30319）。
CLRはPEヘッダーでこの値を使用してロードするDotnetFrameworkのバージョンを決定し、この値はDotnet 4.5に対して構築されたアセンブリでは変更されないため、追加情報がない場合、CLRには次の方法がありません。 PEヘッダーに4.0.30319が含まれるアセンブリで、Dotnet4.0または4.5へのリンクが必要かどうかを確認します。
この追加情報をCLRに提供するのは、app.configにsupportedRuntime要素が含まれていることです。したがって、Dotnet4.0のみがインストールされているシステムにsupportedRuntimeエントリが存在するDotnet4.5アプリケーションを起動すると、CLRは、必要なバージョンのDotnetがインストールされていないことを通知する有用なメッセージをポップアップ表示します。一方、Dotnet4.0のみがインストールされているシステムでsupportedRuntimeエントリなしで同じDotnet4.5アプリケーションを起動すると、アプリケーションの実行が開始される場合がありますが、後でDotnet4.5機能を使用しようとするとクラッシュします。
VS2012 RCを使用して構築され、Dotnet 4.5を対象とするプロジェクトでは、supportedRuntimeエントリが欠落している可能性がありますが、VS2012RTMを使用して構築されたプロジェクトにはエントリがあります。