Microsoft .NET ネイティブに関する FAQ

F# や VB など、よく利用する言語はサポートされていますか。

このプレビュー リリースでは C# コードのみがサポートされています。それは C# コードが .NET 言語としてほとんどのストア アプリで使用されているためですが、対象を広げる際にその他の .NET 言語にも対応する準備はできています。

.NET ネイティブの利点はパフォーマンスのみですか。それとも、Win32/64 にネイティブ コンパイルされた C# コードなどもビルドでき、ターゲット マシンに .NET Framework をインストールする必要がありませんか。

そのとおりです。.NET ネイティブはパフォーマンスだけでなく、生産性と一貫したデバイス エクスペリエンスにも効果を発揮します。.NET ネイティブを使用すると、いつものように、マネージ言語でコードを記述し、MSIL パッケージをアップロードすることができます。ただし、アプリは完全に単体で使用できるネイティブ コンパイルされたコードとしてエンド ユーザー デバイスに配置され (.NET ネイティブの運用開始時)、ターゲット デバイス/マシンで .NET Framework に依存しません。ご存知のように、.NET アプリケーションは幅広く利用されています。このため、弊社では、.NET Framework にも大きな投資を行っています (たとえば、RyuJIT の CTP をリリースしたばかりです)。

.NET ネイティブの開発中にどのようなシナリオを検討しましたか。

想定したシナリオはデバイス向けのストア アプリで、開発者が .NET および MSIL の生産性の利点を維持したまま MSIL パッケージをストアにアップロードし、エンド ユーザーにネイティブ コード (C++) 並みのパフォーマンスを提供できることを目指しました (Windows Phone 8 と類似したクラウドでコンパイルが実行される)。

.NET ネイティブは .NET Micro Framework に代わるものですか。C#/.NET は小型デバイス向けに完全に利用可能になりますか。

.NET ネイティブは現在、Windows ストア アプリに重点を置いています。Micro Framework は Windows Embedded チームが提供し、.NET チームは Windows Embedded チームと協力して顧客へのサービスを最大限に高めることに取り組んでいます。

開発者プレビューで Windows Phone アプリとライブラリを作成できますか。

.NET ネイティブと組み合わせて使用できるユニバーサル クラス ライブラリを作成できます。このプレビューでは、.NET ネイティブを使用して作成できるのは Windows ストア アプリのみです。.NET ネイティブを使用した Windows Phone アプリ開発の実現に現在取り組んでいます。

.NET ネイティブを使用すると、C# 開発者にとってハイエンドなグラフィカル アプリやゲームの開発作業は改善されますか。

改善されます。.NET ネイティブ コンパイラは、一部のコード ベースを Microsoft C++ オプティマイザーと共有しています。

サーバー/デスクトップ アプリには、クラウドで利用する .NET ネイティブやコンパイラの恩恵はありますか。

デスクトップ アプリは、弊社の戦略において非常に重要な位置を占めています。最初は、.NET ネイティブを使用した Windows ストア アプリに重点を置き、長期的には、すべての .NET アプリケーションのネイティブ コンパイルの向上を目指しています。

リンクはどのように動作しますか。フレームワーク コードはアプリケーションにコンパイルされますか。パッケージ/バイナリのサイズにはどのような影響がありますか。

はい、フレームワーク コードはアプリケーションにコンパイルされます。パッケージ サイズに関しては、ほとんどのストア アプリには多数のマルチメディアが含まれているため、大きな違いはありません。 コード サイズは結果的に変わりますが、関係するのはアプリで使用されるフレームワークの部分のみです。最終的には、.NET ネイティブを使用してコンパイルされたバイナリは、NGEN によって生成されたバイナリとほぼ同じサイズになります。 弊社では、サイズの違いをさらに抑えることのできる手段を現在も模索しています。

.NET ネイティブを使用したコンパイルが、MSIL を使用した場合よりも遅いのはなぜですか。

通常のアプリ開発では、Visual Studio の標準的な MSIL/JIT 開発エクスペリエンスを使用しています。.NET ネイティブ コンパイラは、アプリケーションがデバイスに配置され、ほとんどの開発プロセスが終了し、アプリの最適化に焦点が移ってから呼び出されます。この時点で、コンパイル時間はリンク時コード生成で最適化された C++ と同等になります。

P/Invoke はどうなりますか。標準 DLL 呼び出しに最適化されますか。

バイナリはネイティブ コンパイルされますが、マネージ コード タイプの安全性の利点 (つまり、ガベージ コレクション) と完全な C# 例外モデルは維持されます。.NET ネイティブでは、相互運用パスの最適化も十分に行っています。そのため、標準 DLL 呼び出しに対して P/Invoke の最適化は行われませんが、GC 同期と必要なマーシャリングを行うためのオーバーヘッドは最小限に抑えられます。

どのような制限事項がありますか。オープン ジェネリックとリフレクションはサポートされますか。

.NET ネイティブは、稼働時にターゲット プラットフォームがサポートするすべての機能に対応します。この .NET ネイティブは多数の機能を搭載した進行中のプレビュー リリースであるため、現在、いくつかの制限事項が設けられています。ただし、オープン ジェネリックとリフレクションはどちらもこのプレビュー リリースでサポートされています (静的コンパイル時も同様です)。このプレビュー リリースでは、実行時に必要なジェネリックなインスタンス化とメタデータを確認しようとするヒューリスティックがコンパイラに組み込まれています。このため、コンパイラの利点を考慮すると大量のアプリがソースを簡素化せずに "単に動作" すると予想されます。**

これらのアプリには修正プログラムやサービスはどのように適用されますか。

アプリのサービス モデルには変更はありません。フレームワークの場合、.NET の現在のモデルでは、ライブラリの更新プログラムが自動的に提供されます。弊社では、その他の方法も引き続き検討しています。ご提案やご要望がございましたら、ぜひお聞かせください。

未使用のメソッドが削除されている場合、直接呼び出さなくても、メソッド (またはクラス全体) が使用されることを示す方法はありますか。

はい。プレビューでは、直接呼び出さなくても、メソッド (またはタイプ) が使用されることを開発者が示すことができます (ランタイム ディレクティブに関するドキュメントをご覧ください)。