.NET ネイティブの概要Getting Started with .NET Native

Windows 10 用に新しい Windows アプリを作成する場合も、既存の Windows ストア アプリを移行する場合も、次に示す同じ手順を実行することになります。Whether you are writing a new Windows app for Windows 10 or you are migrating an existing Windows Store app, you can follow the same set of procedures. .NET ネイティブアプリを作成するには、次の手順を実行します。To create a .NET Native app, follow these steps:

  1. Windows 10 を対象とするユニバーサル Windows プラットフォーム (UWP) ストア アプリを開発し、アプリのデバッグ ビルドをテストして、そのアプリが適切に動作することを確認します。Develop a Universal Windows Platform (UWP) app that targets Windows 10, and test the debug builds of your app to ensure that it works properly.

  2. 追加のリフレクションおよびシリアル化の使用を処理しますHandle additional reflection and serialization usage.

  3. リリース ビルドのアプリを展開して、テストしますDeploy and test the release builds of your app.

  4. メタデータの欠落を手動で解決し、すべての問題が解決されるまで 手順 3 を繰り返します。Manually resolve missing metadata, and repeat step 3 until all issues are resolved.

注意

既存の Windows ストアアプリを .NET ネイティブに移行する場合は、「 Windows ストアアプリの .NET ネイティブへの移行」を必ず確認してください。If you are migrating an existing Windows Store app to .NET Native, be sure to review Migrating Your Windows Store App to .NET Native.

手順 1: UWP アプリのデバッグ ビルドを開発してテストするStep 1: Develop and test debug builds of your UWP app

新しいアプリを開発するか既存のアプリを移行するかに関係なく、Windows アプリについては同じ手順を実行します。Whether you are developing a new app or migrating an existing one, you follow the same process as for any Windows app.

  1. Visual C# または Visual Basic のユニバーサル Windows アプリ テンプレートを使用して、Visual Studio で新しい UWP プロジェクトを作成します。Create a new UWP project in Visual Studio by using the Universal Windows app template for Visual C# or Visual Basic. 既定では、すべての UWP アプリケーションは CoreCLR を対象としていて、.NET ネイティブ ツール チェーンを使用してリリース ビルドがコンパイルされます。By default, all UWP applications target the CoreCLR and their release builds are compiled by using the .NET Native tool chain.

  2. UWP アプリ プロジェクトのコンパイルに .NET ネイティブ ツール チェーンを使用する場合と使用しない場合では、両者の間に既知の互換性問題がある点にご注意ください。Note that there are some known compatibility issues between compiling UWP app projects with the .NET Native tool chain and without it. 詳細については、 移行ガイド を参照してください。Refer to the migration guide for more information.

ローカルシステム (またC#はシミュレーター) で実行される .NET ネイティブの領域に対して、コードを記述または Visual Basic できるようになりました。You can now write C# or Visual Basic code against the .NET Native surface area that runs on the local system (or in the simulator).

重要

アプリを開発するときに、コードでのシリアル化またはリフレクションを使用する場合は注意してください。As you develop your app, note any use of serialization or reflection in your code.

既定では、デバッグビルドは、F5 を使用した迅速な配置を可能にするために JIT でコンパイルされますが、リリースビルドは .NET ネイティブプリコンパイルテクノロジを使用してコンパイルされます。By default, debug builds are JIT-compiled to enable rapid F5 deployment, while release builds are compiled by using the .NET Native pre-compilation technology. つまり、アプリのデバッグ ビルドが正常に動作するようにするには、.NET ネイティブ ツール チェーンでコンパイルする前に、これをビルドしてテストする必要があるということです。This means you should build and test the debug builds of your app to ensure that they work normally before compiling them with the .NET Native tool chain.

手順 2: 追加のリフレクションおよびシリアル化の使用を処理するStep 2: Handle additional reflection and serialization usage

プロジェクト作成時に Default.rd.xml という名前のランタイム ディレクティブ ファイルがプロジェクトに自動的に追加されます。A runtime directives file, Default.rd.xml, is automatically added to your project when you create it. C# で開発する場合、このファイルはプロジェクトの Properties フォルダーにあります。If you develop in C#, it is found in your project's Properties folder. Visual Basic で開発する場合、このファイルはプロジェクトの My Project フォルダーにあります。If you develop in Visual Basic, it is found in your project's My Project folder.

注意

ランタイム ディレクティブ ファイルが必要となる理由の背景を含む .NET ネイティブのコンパイルの概要については、「 .NET ネイティブとコンパイル」をご覧ください。For an overview of the .NET Native compilation process that provides background on why a runtime directives file is needed, see .NET Native and Compilation.

ランタイム ディレクティブ ファイルは、アプリの実行時に必要なメタデータを定義するために使用されます。The runtime directives file is used to define the metadata that your app needs at run time. この既定バージョンのファイルで十分な場合もあります。In some cases, the default version of the file may be adequate. ただし、シリアル化やリフレクションに依存するコードには、ランタイム ディレクティブ ファイルに追加のエントリが必要になるものがあります。However, some code that relies on serialization or reflection may require additional entries in the runtime directives file.

シリアル化Serialization

シリアライザーには 2 つのカテゴリがあり、これらはいずれもランタイム ディレクティブ ファイルに追加エントリを必要とする場合があります。There are two categories of serializers, and both may require additional entries in the runtime directives file:

  • 非リフレクション ベースのシリアライザー。Non-reflection based serializers. DataContractSerializerDataContractJsonSerializer、および XmlSerializer クラスなど、.NET Framework クラス ライブラリ内にあるシリアライザーは、リフレクションに依存しません。The serializers found in the .NET Framework class library, such as the DataContractSerializer, DataContractJsonSerializer, and XmlSerializer classes, do not rely on reflection. ただし、これらのシリアライザーでは、シリアル化または逆シリアル化されるオブジェクトに基づいてコードが生成される必要があります。However, they do require that code be generated based on the object to be serialized or deserialized. 詳しくは、「 シリアル化とメタデータ」の「Microsoft のシリアライザー」セクションをご覧ください。For more information, see the "Microsoft Serializers" section in Serialization and Metadata.

  • サードパーティ シリアライザー。Third-party serializers. サードパーティ製のシリアル化ライブラリ (最も一般的なものは Newtonsoft JSON シリアライザー) であり、一般的にリフレクションに基づいており、オブジェクトのシリアル化と逆シリアル化をサポートするために *の .xml ファイルにエントリが必要です。Third-party serialization libraries, the most common of which is the Newtonsoft JSON serializer, are generally reflection-based and require entries in the *.rd.xml file to support object serialization and deserialization. 詳しくは、「 シリアル化とメタデータ」の「サードパーティ シリアライザー」セクションをご覧ください。For more information, see the "Third-Party Serializers" section in Serialization and Metadata.

リフレクションに依存するメソッドMethods that rely on reflection

コードでのリフレクションの使用は明確ではない場合があります。In some cases, the use of reflection in code is not obvious. 一般的な API やプログラミング パターンの中には、リフレクション API の一部とは見なされないが、正常な実行にリフレクションを必要とするものがあります。Some common APIs or programming patterns aren't considered part of the reflection API but rely on reflection to execute successfully. これには、次のような型インスタンス化およびメソッド作成方法があります。This includes the following type instantiation and method construction methods:

詳細については、「 リフレクションに依存する API」を参照してください。For more information, see APIs That Rely on Reflection.

注意

ランタイム ディレクティブ ファイルで使用される型名は完全修飾である必要があります。Type names used in runtime directives files must be fully qualified. たとえば、ファイルでは "String" ではなく "System.String" を指定する必要があります。For example, the file must specify "System.String" instead of "String".

手順 3: リリース ビルドのアプリを展開してテストするStep 3: Deploy and test the release builds of your app

ランタイム ディレクティブ ファイルを更新したら、アプリのリリース ビルドを再ビルドして配置できます。After you’ve updated the runtime directives file, you can rebuild and deploy release builds of your app. .NET ネイティブバイナリは、プロジェクトの [プロパティ] ダイアログボックスの [コンパイル] タブにある [ビルド出力パス] テキストボックスで指定されたディレクトリの ILC サブディレクトリに配置されます。このフォルダーにないバイナリはコンパイルされていません.NET ネイティブを使用します。.NET Native binaries are placed in the ILC.out subdirectory of the directory specified in the Build output path text box of the project's Properties dialog box, Compile tab. Binaries that aren't in this folder haven't been compiled with .NET Native. ターゲット プラットフォームごとに、アプリを十分にテストし、失敗シナリオを含むすべてのシナリオをテストします。Test your app thoroughly, and test all scenarios, including failure scenarios, on each of its target platforms.

アプリが正常に動作しない場合 (特に実行時に MissingMetadataException 例外または MissingInteropDataException 例外をスローする場合)、次のセクション「手順 4: メタデータの欠落を手動で解決する」の手順を実行してください。If your app doesn’t work properly (particularly in cases where it throws MissingMetadataException or MissingInteropDataException exceptions at run time), follow the instructions in the next section, Step 4: Manually resolve missing metadata. 初回例外を有効にすると、このようなバグの検出に役立ちます。Enabling first-chance exceptions may help you find these bugs.

アプリのデバッグビルドをテストしてデバッグし、 MissingMetadataException例外とMissingInteropDataException例外を削除したことが確実な場合は、アプリを最適化された .NET ネイティブアプリとしてテストする必要があります。When you’ve tested and debugged the debug builds of your app and you’re confident that you’ve eliminated the MissingMetadataException and MissingInteropDataException exceptions, you should test your app as an optimized .NET Native app. これを行うには、アクティブ プロジェクトの構成を [デバッグ] から [リリース] に変更します。To do this, change your active project configuration from Debug to Release.

手順 4: メタデータの欠落を手動で解決するStep 4: Manually resolve missing metadata

デスクトップでは発生しない .NET ネイティブで発生する最も一般的なエラーは、ランタイムのMissingMetadataExceptionMissingInteropDataException、または誤 singruntimeartifactexception例外です。The most common failure you'll encounter with .NET Native that you don't encounter on the desktop is a runtime MissingMetadataException, MissingInteropDataException, or MissingRuntimeArtifactException exception. メタデータの欠落は、予期しない動作やアプリの失敗によって判明することもあります。In some cases, the absence of metadata can manifest itself in unpredictable behavior or even in app failures. このセクションでは、ランタイム ディレクティブ ファイルにディレクティブを追加することによって、これらの例外をデバッグして解決する方法を説明します。This section discusses how you can debug and resolve these exceptions by adding directives to the runtime directives file. ランタイム ディレクティブの形式については、「ランタイム ディレクティブ (rd.xml) 構成ファイル リファレンス」を参照してださい。For information about the format of runtime directives, see Runtime Directives (rd.xml) Configuration File Reference. ランタイム ディレクティブを追加したら、もう一度 アプリを展開およびテスト して、例外が発生しなくなるまで新しい MissingMetadataExceptionMissingInteropDataException、および MissingRuntimeArtifactException 例外を解決する必要があります。After you’ve added runtime directives, you should deploy and test your app again and resolve any new MissingMetadataException, MissingInteropDataException, and MissingRuntimeArtifactException exceptions until you encounter no more exceptions.

ヒント

高いレベルでランタイム ディレクティブを指定して、アプリがコードの変更に対応できるようにします。Specify the runtime directives at a high level to enable your app to be resilient to code changes. メンバー レベルではなく、名前空間レベルおよび型レベルでランタイム ディレクティブを追加することをお勧めします。We recommend adding runtime directives at the namespace and type levels rather than the member level. 回復性と、バイナリを大きくすることに伴うコンパイル時間の延長の間にはトレードオフがある場合があることに注意してください。Note that there may be a tradeoff between resiliency and larger binaries with longer compile times.

メタデータの欠落例外に対応する場合は、次のことを確認してください。When addressing a missing metadata exception, consider these issues:

  • 例外が発生する前にアプリが何を実行しようとしていたか。What was the app trying to do before the exception?

    • たとえば、データ バインド、シリアル化または逆シリアル化を行っていたか、またはリフレクション API を直接使用していましたか。For example, was it data binding, serializing or deserializing data, or directly using the reflection API?
  • これは特殊なケースか、または他の型でも同じ問題が発生すると考えられるか。Is this an isolated case, or do you believe you'll encounter the same issue for other types?

    • たとえば、 MissingMetadataException 例外は、アプリのオブジェクト モデル内の型をシリアル化するときにスローされます。For example, a MissingMetadataException exception is thrown when serializing a type in the app’s object model. シリアル化されるその他の型がわかっている場合は、それらの型 (または、コードがどの程度構造的に作成されているかによって、それを含む名前空間) に同時にランタイム ディレクティブを追加できます。If you know other types that will be serialized, you can add runtime directives for those types (or for their containing namespaces, depending on how well the code is organized) at the same time.
  • リフレクションを使用しないようにコードを書き換えることができるか。Can you rewrite the code so it doesn’t use reflection?

    • たとえば、予期される型がわかっている場合に、コードで dynamic キーワードが使用されていますか。For example, does the code use the dynamic keyword when you know what type to expect?

    • より適切な他の方法を使用できる場合に、リフレクションに依存するメソッドをコードで呼び出していますか。Does the code call a method that depends on reflection when some better alternative is available?

注意

リフレクションの違い、およびデスクトップアプリと .NET ネイティブでのメタデータの可用性に起因する問題の処理の詳細については、「リフレクションに依存する api」を参照してください。For additional information about handling problems that stem from differences in reflection and the availability of metadata in desktop apps and .NET Native, see APIs That Rely on Reflection.

アプリのテスト時に発生する例外およびその他の問題の処理に関する具体的な例については、次のページを参照してください。For some specific examples of handling exceptions and other issues that occur when testing your app, see:

関連項目See also