次の方法で共有


.NET Native の概要

新しい UWP アプリを作成する場合でも、既存の Windows 8.x アプリ (以前は Microsoft Store アプリとも呼ばれる) を移行する場合でも、同じ手順を実行できます。 .NET ネイティブ アプリを作成するには、次の手順に従います。

  1. ユニバーサル Windows プラットフォーム (UWP) アプリを開発し、アプリのデバッグ ビルドをテストして、正しく動作することを確認します。

  2. 追加のリフレクションとシリアル化の使用を処理します

  3. アプリのリリース ビルドをデプロイしてテストします

  4. 不足しているメタデータを手動で解決し、すべての問題が解決されるまで 手順 3 を繰り返します。

既存の Windows 8.x アプリを .NET Native に移行する場合は、「 Windows 8.x アプリを .NET Native に移行する」を確認してください。

手順 1: UWP アプリのデバッグ ビルドを開発してテストする

新しいアプリを開発する場合でも、既存のアプリを移行する場合でも、Windows アプリの場合と同じプロセスに従います。

  1. Visual C# または Visual Basic 用のユニバーサル Windows アプリ テンプレートを使用して、Visual Studio で新しい UWP プロジェクトを作成します。 既定では、すべての UWP アプリケーションが CoreCLR を対象としており、リリース ビルドは .NET ネイティブ ツール チェーンを使用してコンパイルされます。

  2. .NET ネイティブ ツール チェーンを使用して UWP アプリ プロジェクトをコンパイルし、それを使用せずにコンパイルする場合は、互換性に関する既知の問題がいくつか存在することに注意してください。 詳細については、 移行ガイド を参照してください。

ローカル システム (またはシミュレーター) で実行される .NET ネイティブ のサーフェス領域に対して C# または Visual Basic コードを記述できるようになりました。

Von Bedeutung

アプリを開発するときは、コードでシリアル化またはリフレクションを使用する必要があることに注意してください。

既定では、デバッグ ビルドは JIT コンパイルされ、F5 の迅速なデプロイが可能になりますが、リリース ビルドは .NET ネイティブのプリコンパイル テクノロジを使用してコンパイルされます。 つまり、.NET ネイティブ ツール チェーンを使用してコンパイルする前に、アプリのデバッグ ビルドをビルドしてテストし、正常に動作することを確認する必要があります。

手順 2: リフレクションとシリアル化の追加の使用を処理する

ランタイム ディレクティブ ファイル (Default.rd.xml) は、作成時にプロジェクトに自動的に追加されます。 C# で開発する場合は、プロジェクトの [プロパティ] フォルダーにあります。 Visual Basic で開発する場合は、プロジェクトの [マイ プロジェクト ] フォルダーにあります。

ランタイム ディレクティブ ファイルが必要な理由の背景を提供する .NET ネイティブ コンパイル プロセスの概要については、「.NET Native と Compilationを参照してください。

ランタイム ディレクティブ ファイルは、実行時にアプリに必要なメタデータを定義するために使用されます。 場合によっては、ファイルの既定のバージョンで十分な場合があります。 ただし、シリアル化またはリフレクションに依存する一部のコードでは、ランタイム ディレクティブ ファイルに追加のエントリが必要になる場合があります。

シリアル化

シリアライザーには 2 つのカテゴリがあり、両方ともランタイム ディレクティブ ファイルに追加のエントリが必要になる場合があります。

  • 非リフレクション ベースのシリアライザー。 DataContractSerializerDataContractJsonSerializerXmlSerializer クラスなど、.NET Framework クラス ライブラリ内のシリアライザーはリフレクションに依存しません。 ただし、シリアル化または逆シリアル化するオブジェクトに基づいてコードを生成する必要があります。 詳細については、「 シリアル化とメタデータ」の「Microsoft シリアライザー」セクションを参照してください。

  • サード パーティのシリアライザー。 最も一般的な、Newtonsoft JSON シリアライザーであるサード パーティのシリアル化ライブラリは、一般にリフレクション ベースであり、オブジェクトのシリアル化と逆シリアル化をサポートするために *.rd.xml ファイル内のエントリを必要とします。 詳細については、「 シリアル化とメタデータ」の「サード パーティのシリアライザー」セクションを参照してください。

リフレクションに依存するメソッド

場合によっては、コードでのリフレクションの使用は明白ではありません。 一部の一般的な API またはプログラミング パターンはリフレクション API の一部と見なされず、リフレクションに依存して正常に実行されます。 これには、次の型のインスタンス化とメソッドの構築メソッドが含まれます。

詳細については、「 リフレクションに依存する API」を参照してください。

ランタイム ディレクティブ ファイルで使用される型名は、完全修飾である必要があります。 たとえば、ファイルでは "String" ではなく "System.String" を指定する必要があります。

手順 3: アプリのリリース ビルドをデプロイしてテストする

ランタイム ディレクティブ ファイルを更新したら、アプリのリリース ビルドをリビルドしてデプロイできます。 .NET ネイティブ バイナリは、プロジェクトの [プロパティ] ダイアログ ボックスの [ビルド出力パス テキスト ボックスに指定されたディレクトリの ILC.out サブディレクトリ 配置 タブ。このフォルダーにないバイナリは、.NET Native でコンパイルされていません。 アプリを徹底的にテストし、各ターゲット プラットフォームで障害シナリオを含むすべてのシナリオをテストします。

アプリが正常に動作しない場合(特に、実行時に MissingMetadataException または MissingInteropDataException 例外をスローする場合)、次のセクション「手順 4: 不足しているメタデータを手動で解決する」の指示に従います。 初回例外を有効にすると、これらのバグを見つけるのに役立つ場合があります。

アプリのデバッグ ビルドをテストしてデバッグし、MissingMetadataException と MissingInteropDataException の例外を排除できたと確信している場合、アプリを最適化された .NET ネイティブ アプリとしてテストする必要があります。 これを行うには、アクティブなプロジェクト構成を デバッグ から リリースに変更します。

手順 4: 不足しているメタデータを手動で解決する

デスクトップで発生しない .NET Native で発生する最も一般的なエラーは、MissingMetadataException 、MissingInteropDataException、または MissingRuntimeArtifactException 例外 ランタイムです。 場合によっては、メタデータが存在しない場合、予期しない動作やアプリの障害が発生する可能性があります。 このセクションでは、ランタイム ディレクティブ ファイルにディレクティブを追加することで、これらの例外をデバッグして解決する方法について説明します。 ランタイム ディレクティブの形式については、「 ランタイム ディレクティブ (rd.xml) 構成ファイル リファレンス」を参照してください。 ランタイム ディレクティブを追加したら、アプリ をもう一度デプロイしてテスト し、MissingMetadataException、MissingInteropDataException、MissingRuntimeArtifactException 例外が発生しない限り、新しい を解決する必要があります。

ヒント

アプリがコードの変更に対して回復性を持つように、ランタイム ディレクティブを高レベルで指定します。 メンバー レベルではなく、名前空間レベルと型レベルでランタイム ディレクティブを追加することをお勧めします。 回復性とコンパイル時間が長い大きなバイナリの間にはトレードオフがある可能性があることに注意してください。

不足しているメタデータ例外に対処する場合は、次の問題を考慮してください。

  • アプリは例外の前に何をしようとしていましたか?

    • たとえば、データ バインディング、データのシリアル化または逆シリアル化、リフレクション API を直接使用した場合などです。
  • これは分離されたケースですか、それとも他の種類でも同じ問題が発生すると思いますか?

    • たとえば、MissingMetadataException 例外は、アプリのオブジェクト モデルで型をシリアル化するときにスローされます。 シリアル化されるその他の型がわかっている場合は、それらの型のランタイム ディレクティブ (またはコードの編成方法に応じて、名前空間を含む) を同時に追加できます。
  • リフレクションを使用しないようにコードを書き直すことができますか?

    • たとえば、期待する型がわかっている場合、コードは dynamic キーワードを使用しますか?

    • より良い代替手段が利用可能な場合、コードはリフレクションに依存するメソッドを呼び出しますか?

リフレクションの違いと、デスクトップ アプリと .NET Native でのメタデータの可用性に起因する問題の処理の詳細については、「 リフレクションに依存する API」を参照してください。

アプリのテスト時に発生する例外やその他の問題を処理する具体的な例については、次を参照してください。

こちらも参照ください