.NET NativeとNgen.exeの違いは何ですか？
タイトルがすべてを物語っています。誰かが、Ngen.exeではまだ持っていなかった.NETNativeがテーブルにもたらすものを説明してくれることを望んでいました。
私の知る限り、Ngenはまだフレームワークに依存していますが、よくある質問によると、.NETNativeは本番環境に到達したときにフレームワークに依存しません。
これはパフォーマンスに関するものですか、それともWin32/64にネイティブにコンパイルされてターゲットマシンに.NETFrameworkをインストールする必要のないC＃コード（たとえば）をビルドすることもできますか？
正解です。NETNativeは、パフォーマンスだけでなく、生産性と一貫したデバイスエクスペリエンスにも関係しています。 .NET Nativeを使用すると、管理言語を使用してコードを記述し、いつものようにMSILパッケージをアップロードできます。 ただし、アプリは完全に自己完結型のネイティブにコンパイルされたコードとしてエンドユーザーデバイスにデプロイされ（.NET Nativeが本番環境に入るとき）、. NETFrameworkに依存しません。ターゲットデバイス/マシン。ご存知のように、.NETアプリケーションは幅広い範囲に及びます。したがって、完全な.NET Frameworkにも多額の投資を行っています（たとえば、RyuJITのCTPをリリースしたばかりです）。
.NET Nativeは、デスクトップCLRが使用するNGenテクノロジーの進化形と考えることができます。 .NETNativeとNGENの主な違いはいくつかあります-
- ランタイム依存関係-NGENはフルデスクトップCLRを使用し、.NET Nativeはアプリケーションローカルであるリファクタリングされたランタイム（mrt100_app.dll）を使用します。 .NETネイティブランタイムがリファクタリングされ、ほとんどの機能がアプリケーションからコード生成ツールチェーンに移動しました。これにより、はるかに小さくなり、プレイの費用が増え、（うまくいけば）実行時のデバッグが容易になります。 .NETネイティブアプリケーションも自己完結型であり、アプリケーションにとって便利なプロパティです。
- ネイティブイメージの依存関係-NGENイメージは、実行対象のCLRとその依存アセンブリのNGENイメージの両方に緊密にバインドされています。これにより、たとえば、mscorlib.dllにバグ修正が行われたときに、ほぼすべてのNGENイメージを再生成する必要があります。
- コンパイル場所-。NET Nativeの目的は、アプリストアでネイティブコードを生成することです。 NGENは、エンドユーザーデバイスでネイティブコードを生成します。特定のクラスのデバイス（電話、タブレットなど）では、エンドユーザーのバッテリー寿命を生成するコードを無駄にしたくないことは確かに想像できます。ストアでコンパイルすると、.NET Nativeはコンパイルにより多くの時間を費やすことができるため、NGENが許容できるよりも多くの最適化を適用できます。
- コードジェネレーター-NGENはJITコンパイラーを使用してコードを生成し、.NETNativeはVisualC++コンパイラーのバックエンドを使用します。これにより、JITに適用するにはコストがかかりすぎる自動ベクトル化などの最適化を適用できます。場合
- プログラム全体の分析-NGENは、一度に1つのアセンブリのコードを生成します。これにより、NGENイメージを複数のアプリケーションコンテキストで使用できます。 .NET Nativeは、アプリケーションパッケージ全体のコードを生成します。これにより、より広範な最適化のセットを適用できます（たとえば、実行時に使用されたことのないコードを完全に破棄します）。これは、これらの最適化を可能な限り開始できるようにするリファクタリングされたフレームワークと組み合わされています。
- ILフォールバック-NGENイメージには、（他のデータ構造の中でも）アセンブリのネイティブコードとMSILの両方が含まれています。実行時に何かが発生し、CLRがNGENイメージで見つけられないネイティブコードを必要とする場合、JITingにフォールバックできます。 .NET Nativeの現在の開発者プレビューでは、ネイティブコードのみがネイティブイメージに存在します。これは、コードがイメージに存在しない場合、実行時に実行されないことを意味します。