Windows ストア アプリの .NET ネイティブへの移行Migrating Your Windows Store App to .NET Native

.NET ネイティブ アプリ、Windows ストアまたは開発者のコンピューター上の静的なコンパイルを提供します。.NET Native provides static compilation of apps in the Windows Store or on the developer’s computer. これは、デバイス上で Just-In-Time (JIT) コンパイラまたは ネイティブ イメージ ジェネレーター (Ngen.exe) によって Windows ストア アプリに対して実行される動的なコンパイルとは異なります。This differs from the dynamic compilation performed for Windows Store apps by the just-in-time (JIT) compiler or the Native Image Generator (Ngen.exe) on the device. 違いは、.NET ネイティブ試行との互換性を維持するために、 Windows ストア アプリ用 .NETします。Despite the differences, .NET Native tries to maintain compatibility with the .NET for Windows Store apps. ほとんどの場合、Windows ストア アプリ用 .NET で機能する機能は、.NET ネイティブでも動作します。For the most part, things that work on the .NET for Windows Store apps also work with .NET Native. ただし、動作に違いがある場合もあります。However, in some cases, you may encounter behavioral changes. このドキュメントでは、次の領域で、標準的な Windows ストア アプリ用 .NET と .NET ネイティブのこれらの違いについて説明します。This document discusses these differences between the standard .NET for Windows Store apps and .NET Native in the following areas:

全般的なランタイムの違いGeneral runtime differences

  • 例外などTypeLoadException共通のアプリを実行すると、JIT コンパイラによってスローされる言語ランタイム (CLR) は、通常、.NET ネイティブで処理すると、コンパイル時エラーになります。Exceptions, such as TypeLoadException, that are thrown by the JIT compiler when an app runs on the common language runtime (CLR) generally result in compile-time errors when processed by .NET Native.

  • アプリの UI スレッドから GC.WaitForPendingFinalizers メソッドを呼び出さないでください。Don't call the GC.WaitForPendingFinalizers method from an app's UI thread. これは、結果、.NET ネイティブのデッドロック。This can result in a deadlock on .NET Native.

  • 静的クラス コンストラクターの呼び出し順序に依存しないでください。Don't rely on static class constructor invocation ordering. .NET ネイティブでは、呼び出し順序が標準ランタイムでの順序と異なるです。In .NET Native, the invocation order is different from the order on the standard runtime. (標準ランタイムを使用する場合であっても、静的クラス コンストラクターの実行順序に依存しないでください。)(Even with the standard runtime, you shouldn't rely on the order of execution of static class constructors.)

  • スレッドでの呼び出しを行わない無限ループ (たとえば、 while(true);) によって、アプリが停止する可能性があります。Infinite looping without making a call (for example, while(true);) on any thread may bring the app to a halt. 同様に、長時間または無限の待機によってもアプリが停止する可能性があります。Similarly, large or infinite waits may bring the app to a halt.

  • 特定の汎用初期化サイクルは、.NET ネイティブで例外をスローしません。Certain generic initialization cycles don't throw exceptions in .NET Native. たとえば、次のコードは標準 CLR では TypeLoadException 例外をスローします。For example, the following code throws a TypeLoadException exception on the standard CLR. .NET ネイティブでは、以下のことはしません。In .NET Native, it doesn't.

    using System;
    struct N<T> {}
    struct X { N<X> x; }
    public class Example
       public static void Main()
          N<int> n = new N<int>();
          X x = new X();
  • 場合によっては、.NET ネイティブは、.NET Framework クラス ライブラリのさまざまな実装を提供します。In some cases, .NET Native provides different implementations of .NET Framework class libraries. メソッドから返されるオブジェクトは、常に、返される型のメンバーを実装します。An object returned from a method will always implement the members of the returned type. ただし、その補助的な実装が異なるため、その他の .NET Framework プラットフォームの場合と同じ型セットへのオブジェクトのキャストを行うことができない場合があります。However, since its backing implementation is different, you may not be able to cast it to the same set of types as you could on other .NET Framework platforms. たとえば、 IEnumerable<T>TypeInfo.DeclaredMembers などのメソッドにより返される TypeInfo.DeclaredProperties インターフェイス オブジェクトを T[]にキャストできない場合があります。For example, in some cases, you may not be able to cast the IEnumerable<T> interface object returned by methods such as TypeInfo.DeclaredMembers or TypeInfo.DeclaredProperties to T[].

  • WinInet キャッシュは既定では、Windows Store 用の .NET アプリで有効になっていないが、.NET ネイティブで実行されます。The WinInet cache isn't enabled by default on .NET for Windows Store apps, but it is on .NET Native. これによりパフォーマンスが向上しますが、作業セットへの影響があります。This improves performance but has working set implications. 開発者のアクションは必要ありません。No developer action is necessary.

動的プログラミングの違いDynamic programming differences

.NET ネイティブを静的にリンクからコードをアプリのローカルのパフォーマンスを最大にするための .NET Framework コード。.NET Native statically links in code from the .NET Framework to make the code app-local for maximum performance. ただし、バイナリ サイズは小さいままである必要があるため、.NET Framework 全体を取り入れることはできません。However, binary sizes have to remain small, so the entire .NET Framework can't be brought in. .NET ネイティブ コンパイラは、未使用のコードへの参照を削除する依存関係レジューサを使用して、この制限を解決します。The .NET Native compiler resolves this limitation by using a dependency reducer that removes references to unused code. ただし、.NET ネイティブが維持または生成しないいくつかの種類の情報とコードときに、その情報は、コンパイル時に静的に推論することはできませんが、実行時に動的に取得が代わりにします。However, .NET Native might not maintain or generate some type information and code when that information can't be inferred statically at compile time, but instead is retrieved dynamically at runtime.

リフレクションと動的プログラミング、.NET ネイティブのメッセージが有効にします。.NET Native does enable reflection and dynamic programming. ただし、すべての型をリフレクション対象としてマークできるわけではありません。そうすると、生成されるコード サイズが大きくなりすぎるため (特に、.NET Framework での パブリック API へのリフレクションがサポートされているため) です。However, not all types can be marked for reflection, because this would make the generated code size too large (especially because reflecting on public APIs in the .NET Framework is supported). .NET ネイティブ コンパイラは、スマートの選択肢については、型でリフレクションをサポートする必要があると、メタデータを保持し、それらの型に対してのみコードを生成します。The .NET Native compiler makes smart choices about which types should support reflection, and it keeps the metadata and generates code only for those types.

たとえば、データ バインディングは、プロパティ名を関数にマップするためにアプリを必要とします。For example, data binding requires an app to be able to map property names to functions. Windows ストア アプリ用 .NET では、共通言語ランタイムが自動的にリフレクションを使用して、マネージド型および公開されているネイティブ型にこの機能を提供します。In .NET for Windows Store apps, the common language runtime automatically uses reflection to provide this capability for managed types and publicly available native types. .NET ネイティブで、コンパイラは、データのバインド先の種類のメタデータを自動的に含めます。In .NET Native, the compiler automatically includes metadata for types to which you bind data.

.NET ネイティブでコンパイラで処理できることもよく使用されるジェネリック型がなどList<T>Dictionary<TKey,TValue>をヒントやディレクティブなしで機能します。The .NET Native compiler can also handle commonly used generic types such as List<T> and Dictionary<TKey,TValue>, which work without requiring any hints or directives. dynamic キーワードも、一定の制限の下でサポートされます。The dynamic keyword is also supported within certain limits.


.NET ネイティブ アプリを移植するときに、すべての動的コード パスを徹底的にテストしてください。You should test all dynamic code paths thoroughly when porting your app to .NET Native.

.NET ネイティブの既定の構成は、ほとんどの開発者だけで十分ですが、ランタイム ディレクティブを使用してその構成を fine を調整する一部の開発者 (. rd.xml) ファイル。The default configuration for .NET Native is sufficient for most developers, but some developers might want to fine- tune their configurations by using a runtime directives (.rd.xml) file. さらに、場合によっては、.NET ネイティブ コンパイラはメタデータのリフレクションで使用できる必要があり、次の場合に特に、ヒントを確認できません。In addition, in some cases, the .NET Native compiler is unable to determine which metadata must be available for reflection and relies on hints, particularly in the following cases:

  • Type.MakeGenericTypeMethodInfo.MakeGenericMethod などの一部の構造体は、静的に決定できません。Some constructs like Type.MakeGenericType and MethodInfo.MakeGenericMethod can't be determined statically.

  • コンパイラでインスタンス化を決定できないため、リフレクション対象のジェネリック型をランタイム ディレクティブで指定する必要があります。Because the compiler can't determine the instantiations, a generic type that you want to reflect on has to be specified by runtime directives. これは、すべてのコードを含める必要があるだけではなく、ジェネリック型へのリフレクションによって無限サイクルが生じる可能性があるためです (たとえば、ジェネリック型でジェネリック メソッドが呼び出された場合)。This isn't just because all code must be included, but because reflection on generic types can form an infinite cycle (for example, when a generic method is invoked on a generic type).


ランタイム ディレクティブは、ランタイム ディレクティブ (.rd.xml) ファイルで定義されます。Runtime directives are defined in a runtime directives (.rd.xml) file. このファイルの使用方法に関する全般的な情報は、「Getting Started with .NET Native」(.NET ネイティブの概要) をご覧ください。For general information about using this file, see Getting Started. ランタイム ディレクティブについては、「 Runtime Directives (rd.xml) Configuration File Reference」をご覧ください。For information about the runtime directives, see Runtime Directives (rd.xml) Configuration File Reference.

.NET ネイティブも含まれています、開発者の既定セット以外のどの型がリフレクションをサポートする決定に役立つツールをプロファイリングします。.NET Native also includes profiling tools that help the developer determine which types outside the default set should support reflection.

その他の個別リフレクション関連の動作の違い、Windows ストア アプリ用 .NET と .NET ネイティブを数多くあります。There are a number of other individual reflection-related differences in behavior between the .NET for Windows Store apps and .NET Native.

.NET ネイティブ。In .NET Native:

  • .NET Framework クラス ライブラリでの型とメンバーに対するプライベート リフレクションはサポートされません。Private reflection over types and members in the .NET Framework class library is not supported. ただし、独自のプライベート型とメンバー、およびサードパーティ ライブラリの型とメンバーに対するリフレクションは行うことができます。You can, however, reflect over your own private types and members, as well as types and members in third-party libraries.

  • ParameterInfo.HasDefaultValue プロパティは、戻り値を表す false オブジェクトに対し、正しく ParameterInfo を返します。The ParameterInfo.HasDefaultValue property correctly returns false for a ParameterInfo object that represents a return value. Windows ストア アプリ用 .NET の場合、これは trueを返します。In the .NET for Windows Store apps, it returns true. 中間言語 (IL) はこれを直接サポートせず、解釈は言語に任されます。Intermediate language (IL) doesn’t support this directly, and interpretation is left to the language.

  • RuntimeFieldHandle 構造体と RuntimeMethodHandle 構造体のパブリック メンバーはサポートされません。Public members on the RuntimeFieldHandle and RuntimeMethodHandle structures aren't supported. これらの型は、LINQ、式ツリー、および静的な配列の初期化でのみサポートされます。These types are supported only for LINQ, expression trees, and static array initialization.

  • RuntimeReflectionExtensions.GetRuntimePropertiesRuntimeReflectionExtensions.GetRuntimeEvents の基底クラスには隠ぺいされたメンバーが含まれるため、明示的なオーバーライドなしでオーバーライドできます。RuntimeReflectionExtensions.GetRuntimeProperties and RuntimeReflectionExtensions.GetRuntimeEvents include hidden members in base classes and thus may be overridden without explicit overrides. これは、その他の RuntimeReflectionExtensions.GetRuntime* メソッドの場合も同様です。This is also true of other RuntimeReflectionExtensions.GetRuntime* methods.

  • Type.MakeArrayTypeType.MakeByRefType は、特定の組み合わせ (たとえば、byref の配列) を作成しようとしたときに失敗しません。Type.MakeArrayType and Type.MakeByRefType don't fail when you try to create certain combinations (for example, an array of byrefs).

  • リフレクションを使用して、ポインター パラメーターを持つメンバーを呼び出すことはできません。You can't use reflection to invoke members that have pointer parameters.

  • リフレクションを使用して、ポインター フィールドを取得または設定することはできません。You can't use reflection to get or set a pointer field.

  • 引数の数が間違っていると、引数の 1 つの種類が正しくない、.NET ネイティブをスローするArgumentExceptionの代わりに、TargetParameterCountExceptionします。When the argument count is wrong and the type of one of the arguments is incorrect, .NET Native throws an ArgumentException instead of a TargetParameterCountException.

  • 通常、例外のバイナリ シリアル化はサポートされません。Binary serialization of exceptions is generally not supported. そのため、シリアル化不可能なオブジェクトを Exception.Data ディクショナリに追加できます。As a result, non-serializable objects can be added to the Exception.Data dictionary.

サポートされていないシナリオと APIUnsupported scenarios and APIs

次のセクションに、全般的な開発、相互運用、および HTTPClient や Windows Communication Foundation (WCF) などの技術でサポートされないシナリオと API を示します。The following sections list unsupported scenarios and APIs for general development, interop, and technologies such as HTTPClient and Windows Communication Foundation (WCF):

全般的な開発の違いGeneral development differences

値型Value types

  • 値型の ValueType.Equals メソッドと ValueType.GetHashCode メソッドをオーバーライドする場合は、基底クラスの実装を呼び出さないでください。If you override the ValueType.Equals and ValueType.GetHashCode methods for a value type, don't call the base class implementations. Windows ストア アプリ用 .NET では、これらのメソッドはリフレクションに依存します。In .NET for Windows Store apps, these methods rely on reflection. コンパイル時に、.NET ネイティブは、ランタイム リフレクションに依存しない実装を生成します。At compile time, .NET Native generates an implementation that doesn't rely on runtime reflection. これは、これら 2 つのメソッドを上書きしない場合は期待どおりに動作を .NET ネイティブ コンパイル時に実装を生成するためを意味します。This means that if you don't override these two methods, they will work as expected, because .NET Native generates the implementation at compile time. ただし、基底クラスの実装を呼び出さずにこれらのメソッドをオーバーライドすると、例外が発生します。However, overriding these methods but calling the base class implementation results in an exception.

  • 1 メガバイトより大きい値型はサポートされません。Value types larger than one megabyte aren't supported.

  • 値の型は、.NET ネイティブで既定のコンス トラクターを持つことはできません。Value types can't have a default constructor in .NET Native. (C# と Visual Basic では、値型の既定のコンストラクターが許可されません。(C# and Visual Basic prohibit default constructors on value types. ただし、IL ではこれらを作成できます。)However, these can be created in IL.)


  • ゼロ以外の下限を持つ配列はサポートされません。Arrays with a lower bound other than zero aren't supported. 通常、これらの配列は Array.CreateInstance(Type, Int32[], Int32[]) オーバーロードを呼び出すことで作成されます。Typically, these arrays are created by calling the Array.CreateInstance(Type, Int32[], Int32[]) overload.

  • 多次元配列の動的作成はサポートされません。Dynamic creation of multidimensional arrays isn't supported. そのような配列は通常、Array.CreateInstance パラメーターを含む lengths メソッドのオーバーロードを呼び出すか、Type.MakeArrayType(Int32) メソッドを呼び出すことで作成されます。Such arrays are typically created by calling an overload of the Array.CreateInstance method that includes a lengths parameter, or by calling the Type.MakeArrayType(Int32) method.

  • 4 つ以上の次元を持つ多次元配列 (つまり、 Array.Rank プロパティ値が 4 以上のもの) はサポートされません。Multidimensional arrays that have four or more dimensions aren't supported; that is, their Array.Rank property value is four or greater. 代わりに ジャグ配列 (配列の配列) を使用してください。Use jagged arrays (an array of arrays) instead. たとえば、 array[x,y,z] は無効ですが、 array[x][y][z] は有効です。For example, array[x,y,z] is invalid, but array[x][y][z] isn't.

  • 多次元配列の共変性はサポートされず、実行時に InvalidCastException 例外を発生させます。Variance for multidimensional arrays isn't supported and causes an InvalidCastException exception at run time.


  • ジェネリック型の無限展開はコンパイル エラーになります。Infinite generic type expansion results in a compiler error. たとえば、このコードはコンパイルに失敗します。For example, this code fails to compile:

    class A<T> {}
    class B<T> : A<B<A<T>>> 


  • ポインターの配列はサポートされていません。Arrays of pointers aren't supported.

  • リフレクションを使用して、ポインター フィールドを取得または設定することはできません。You can't use reflection to get or set a pointer field.


KnownTypeAttribute(String) 属性はサポートされていません。The KnownTypeAttribute(String) attribute isn't supported. 代わりに KnownTypeAttribute(Type) 属性を使用してください。Use the KnownTypeAttribute(Type) attribute instead.


EventSource クラスでのローカライズされたリソースの使用はサポートされません。The use of localized resources with the EventSource class isn't supported. EventSourceAttribute.LocalizationResources プロパティはローカライズされたリソースを定義しません。The EventSourceAttribute.LocalizationResources property doesn't define localized resources.


Delegate.BeginInvokeDelegate.EndInvoke はサポートされません。Delegate.BeginInvoke and Delegate.EndInvoke aren't supported.

その他の APIMiscellaneous APIs

  • TypeInfo.GUID 属性が型に適用されない場合、 PlatformNotSupportedException プロパティは GuidAttribute 例外をスローします。The TypeInfo.GUID property throws a PlatformNotSupportedException exception if a GuidAttribute attribute isn't applied to the type. GUID は主に COM サポートで使用されます。The GUID is used primarily for COM support.

  • DateTime.Parseメソッドは、.NET ネイティブで、短い日付を含む文字列を正しく解析します。The DateTime.Parse method correctly parses strings that contain short dates in .NET Native. ただし、Microsoft サポート技術情報の記事 KB2803771KB2803755で説明されている日付と時刻の解析の変更に対する互換性は保持されません。However, it doesn't maintain compatibility with the changes in date and time parsing described in the Microsoft Knowledge Base articles KB2803771 and KB2803755.

  • BigInteger.ToString ("E") .NET ネイティブで正しく丸められます。BigInteger.ToString ("E") is correctly rounded in .NET Native. CLR の一部のバージョンでは、結果の文字列が丸められるのではなく、切り捨てられます。In some versions of the CLR, the result string is truncated instead of rounded.

HttpClient の違いHttpClient differences

.NET ネイティブで、HttpClientHandlerクラス WinINet を内部的に使用する (を通じて、HttpBaseProtocolFilterクラス) の代わりに、WebRequestWebResponse標準的な Windows ストア アプリ用 .NET で使用されるクラス。In .NET Native, the HttpClientHandler class internally uses WinINet (through the HttpBaseProtocolFilter class) instead of the WebRequest and WebResponse classes used in the standard .NET for Windows Store apps. WinINet では、 HttpClientHandler クラスでサポートされる構成オプションがすべてサポートされるわけではありません。WinINet doesn't support all the configuration options that the HttpClientHandler class supports. 結果は次のようになります。As a result:

  • 機能プロパティの一部HttpClientHandler返すfalse.NET ネイティブで返す一方true標準的な Windows ストア アプリ用 .NET でします。Some of the capability properties on HttpClientHandler return false on .NET Native, whereas they return true in the standard .NET for Windows Store apps.

  • 構成プロパティの一部getアクセサーは常に、.NET ネイティブで Windows ストア アプリ用 .NET の既定の構成可能な値とは異なる固定値を返します。Some of the configuration property get accessors always return a fixed value on .NET Native that is different than the default configurable value in .NET for Windows Store apps.

次のサブセクションで、その他の動作の違いについて説明します。Some additional behavior differences are covered in the following subsections.


HttpBaseProtocolFilterクラスは、構成と、要求ごとに、プロキシのオーバーライドをサポートしていません。The HttpBaseProtocolFilter class doesn’t support configuring or overriding the proxy on a per-request basis. つまり、.NET ネイティブのすべての要求使用システムに構成されたプロキシ サーバーまたはプロキシ サーバーなしの値に応じて、HttpClientHandler.UseProxyプロパティ。This means that all requests on .NET Native use the system-configured proxy server or no proxy server, depending on the value of the HttpClientHandler.UseProxy property. Windows ストア アプリ用 .NET では、プロキシ サーバーは HttpClientHandler.Proxy プロパティにより定義されます。In .NET for Windows Store apps, the proxy server is defined by the HttpClientHandler.Proxy property. .NET ネイティブでの設定で、HttpClientHandler.Proxy以外の値をnullスロー、PlatformNotSupportedException例外。On .NET Native, setting the HttpClientHandler.Proxy to a value other than null throws a PlatformNotSupportedException exception. HttpClientHandler.SupportsProxyプロパティが返すfalseで .NET ネイティブが返されますが、true標準の .NET Framework の Windows ストア アプリで。The HttpClientHandler.SupportsProxy property returns false on .NET Native, whereas it returns true in the standard .NET Framework for Windows Store apps.

自動リダイレクトAutomatic redirection

HttpBaseProtocolFilterクラスを構成する自動リダイレクトの最大数が許可されません。The HttpBaseProtocolFilter class doesn't allow the maximum number of automatic redirections to be configured. 標準の Windows ストア アプリ用 .NET での HttpClientHandler.MaxAutomaticRedirections プロパティの値は既定で 50 で、変更できません。The value of the HttpClientHandler.MaxAutomaticRedirections property is 50 by default in the standard .NET for Windows Store apps and can be modified. このプロパティの値は 10 がスローされますを変更しようと .NET ネイティブのPlatformNotSupportedException例外。On .NET Native, the value of this property is 10, and trying to modify it throws a PlatformNotSupportedException exception. HttpClientHandler.SupportsRedirectConfigurationプロパティが返すfalseで .NET ネイティブが返されますが、 true Windows ストア アプリ用 .NET で。The HttpClientHandler.SupportsRedirectConfiguration property returns false on .NET Native, whereas it returns true in .NET for Windows Store apps.

自動展開Automatic decompression

Windows ストア アプリ用 .NET では、 HttpClientHandler.AutomaticDecompression プロパティを DeflateGZipDeflateGZipの両方、または Noneに設定できます。.NET for Windows Store apps allows you to set the HttpClientHandler.AutomaticDecompression property to Deflate, GZip, both Deflate and GZip, or None. .NET ネイティブのみをサポートDeflateと共にGZip、またはNoneします。.NET Native only supports Deflate together with GZip, or None. AutomaticDecompression プロパティを Deflate のみまたは GZip のみに設定しようとすると、 DeflateGZipの両方に自動的に設定されます。Trying to set the AutomaticDecompression property to either Deflate or GZip alone silently sets it to both Deflate and GZip.


クッキーの処理は、 HttpClient と WinINet により同時に行われます。Cookie handling is performed simultaneously by HttpClient and WinINet. CookieContainer のクッキーは、WinINet クッキー キャッシュのクッキーと組み合わされます。Cookies from the CookieContainer are combined with cookies in the WinINet cookie cache. CookieContainer のクッキーを削除すると HttpClient からクッキーが送信されませんが、クッキーが既に WinINet に示されており、ユーザーによって削除されない場合、WinINet がクッキーを送信します。Removing a cookie from CookieContainer prevents HttpClient from sending the cookie, but if the cookie was already seen by WinINet, and cookies weren't deleted by the user, WinINet sends it. HttpClientHttpClientHandler、または CookieContainer API を使用して、プログラムにより WinINet からクッキーを削除することはできません。It isn't possible to programmatically remove a cookie from WinINet by using the HttpClient, HttpClientHandler, or CookieContainer API. HttpClientHandler.UseCookies プロパティを false に設定しても、 HttpClient からクッキーが送信されなくなるのみで、WinINet の要求にはまだそのクッキーが含まれている可能性があります。Setting the HttpClientHandler.UseCookies property to false causes only HttpClient to stop sending cookies; WinINet might still include its cookies in the request.


Windows ストア アプリ用 .NET では、 HttpClientHandler.UseDefaultCredentials プロパティと HttpClientHandler.Credentials プロパティは独立して動作します。In .NET for Windows Store apps, the HttpClientHandler.UseDefaultCredentials and HttpClientHandler.Credentials properties work independently. また、 Credentials プロパティは ICredentials インターフェイスを実装するオブジェクトをすべて受け入れます。Additionally, the Credentials property accepts any object that implements the ICredentials interface. .NET ネイティブでの設定で、UseDefaultCredentialsプロパティをtrueにより、Credentialsになるプロパティnullします。In .NET Native, setting the UseDefaultCredentials property to true causes the Credentials property to become null. さらに、 Credentials プロパティは、 nullDefaultCredentials、または NetworkCredential型のオブジェクトにしか設定できません。In addition, the Credentials property can be set only to null, DefaultCredentials, or an object of type NetworkCredential. その他の ICredentials オブジェクト (最も一般的なものは CredentialCache) を Credentials プロパティに割り当てると、 PlatformNotSupportedExceptionがスローされます。Assigning any other ICredentials object, the most popular of which is CredentialCache, to the Credentials property throws a PlatformNotSupportedException.

その他のサポートされていない機能または構成できない機能Other unsupported or unconfigurable features

.NET ネイティブ。In .NET Native:

相互運用の違いInterop differences

非推奨の APIDeprecated APIs

マネージド コードで相互運用性のために使用される頻度が低い API のいくつかが、非推奨にされました。A number of infrequently used APIs for interoperability with managed code have been deprecated. これらの Api がスローされる .NET ネイティブと共に使用すると、NotImplementedExceptionまたはPlatformNotSupportedException例外、またはコンパイラ エラーが発生します。When used with .NET Native, these APIs may throw a NotImplementedException or PlatformNotSupportedException exception, or result in a compiler error. Windows ストア アプリ用 .NET では、これらの API は廃止としてマークされていますが、これらの API を呼び出すとコンパイラ エラーではなくコンパイラの警告が生成されます。In .NET for Windows Store apps, these APIs are marked as obsolete, although calling them generates a compiler warning rather than a compiler error.

非推奨の Api のVARIANTマーシャ リングが含まれます。Deprecated APIs for VARIANT marshaling include:

UnmanagedType.Struct はサポートされていますが、 IDispatch や byref バリアントと共に使用された場合など、一部のシナリオでは例外がスローされます。UnmanagedType.Struct is supported, but it throws an exception in some scenarios, such as when it is used with IDispatch or byref variants.

非推奨の Api のIDispatchサポートが含まれます。Deprecated APIs for IDispatch support include:

クラシック COM イベント用の非推奨の Api は次のとおりです。Deprecated APIs for classic COM events include:

非推奨の Api で、System.Runtime.InteropServices.ICustomQueryInterfaceインターフェイスでは、.NET ネイティブでサポートされていないが含まれます。Deprecated APIs in the System.Runtime.InteropServices.ICustomQueryInterface interface, which isn't supported in .NET Native, include:

サポートされていないその他の相互運用機能は次のとおりです。Other unsupported interop features include:

ほとんど使用されないマーシャリング API:Rarely used marshalling APIs:

プラットフォーム呼び出しと COM 相互運用の互換性Platform invoke and COM interop compatibility

ほとんどのプラットフォーム呼び出しし、COM 相互運用シナリオは引き続き .NET ネイティブでサポートされます。Most platform invoke and COM interop scenarios are still supported in .NET Native. 特に、Windows ランタイム (WinRT) API とのすべての相互運用性と Windows ランタイムで必要なすべてのマーシャリングがサポートされます。In particular, all interoperability with Windows Runtime (WinRT) APIs and all marshaling required for the Windows Runtime is supported. これには、次のものに対するマーシャリング サポートが含まれます。This includes marshaling support for:

ただし、.NET ネイティブは以下をサポートします。However, .NET Native doesn't support the following:

リフレクションを使用したプラットフォーム呼び出しメソッドの呼び出しはサポートされません。Using reflection to invoke a platform invoke method isn't supported. この制限を回避するには、別のメソッドでメソッド呼び出しをラップし、リフレクションを使用してラッパーを代わりに呼び出します。You can work around this limitation by wrapping the method call in another method and using reflection to call the wrapper instead.

その他の Windows ストア アプリ用 .NET API との違いOther differences from .NET APIs for Windows Store apps

このセクションでは、.NET ネイティブでサポートされていない他の Api を示します。This section lists the remaining APIs that aren't supported in .NET Native. サポートされない API で最も多いのは、Windows Communication Foundation (WCF) API です。The largest set of the unsupported APIs are Windows Communication Foundation (WCF) APIs.

DataAnnotations (System.ComponentModel.DataAnnotations)DataAnnotations (System.ComponentModel.DataAnnotations)

内の型、System.ComponentModel.DataAnnotationsSystem.ComponentModel.DataAnnotations.Schema名前空間は .NET ネイティブでサポートされていません。The types in the System.ComponentModel.DataAnnotations and System.ComponentModel.DataAnnotations.Schema namespaces aren't supported in .NET Native. Windows 8 用 .NET の Windows ストア アプリに存在する次の種類が含まれます。These include the following types that are present in .NET for Windows Store apps for Windows 8:

Visual BasicVisual Basic

現在の .NET ネイティブでは、Visual Basic がサポートされていません。Visual Basic isn't currently supported in .NET Native. 次の型は、Microsoft.VisualBasicMicrosoft.VisualBasic.CompilerServices名前空間は .NET ネイティブでは使用できません。The following types in the Microsoft.VisualBasic and Microsoft.VisualBasic.CompilerServices namespaces aren't available in .NET Native:

リフレクション コンテキスト (System.Reflection.Context 名前空間)Reflection Context (System.Reflection.Context namespace)

System.Reflection.Context.CustomReflectionContextクラスは .NET ネイティブでサポートされていません。The System.Reflection.Context.CustomReflectionContext class isn't supported in .NET Native.

RTC (System.Net.Http.Rtc)RTC (System.Net.Http.Rtc)

System.Net.Http.RtcRequestFactoryクラスは .NET ネイティブでサポートされていません。The System.Net.Http.RtcRequestFactory class isn't supported in .NET Native.

Windows Communication Foundation (WCF) (System.ServiceModel.*)Windows Communication Foundation (WCF) (System.ServiceModel.*)

内の型、 System.ServiceModel.* 名前空間は .NET ネイティブでサポートされていません。The types in the System.ServiceModel.* namespaces aren't supported in .NET Native. そうした型には、次のようなものがあります。These includes the following types:

シリアライザーの違いDifferences in serializers

DataContractSerializerDataContractJsonSerializer、および XmlSerializer クラスによるシリアル化と逆シリアル化に関する違いを次に示します。The following differences concern serialization and deserialization with the DataContractSerializer, DataContractJsonSerializer, and XmlSerializer classes:

Visual Studio の違いVisual Studio differences

例外とデバッグExceptions and debugging

デバッガーで .NET ネイティブを使用してコンパイルされたアプリを実行している初回の例外は次の例外の種類を有効になります。When you're running apps compiled by using .NET Native in the debugger, first-chance exceptions are enabled for the following exception types:

アプリのビルドBuilding apps

Visual Studio で既定で使用される x86 ビルド ツールを使用します。Use the x86 build tools that are used by default by Visual Studio. C:\Program Files (x86)\MSBuild\12.0\bin\amd64 にある AMD64 MSBuild ツールは、ビルドの問題が発生する可能性があるため、使用しないことをお勧めします。We don't recommend using the AMD64 MSBuild tools, which are found in C:\Program Files (x86)\MSBuild\12.0\bin\amd64; these may create build problems.


  • Visual Studio CPU プロファイラーと XAML メモリ プロファイラーでは、マイ コードのみは正しく表示されません。The Visual Studio CPU Profiler and XAML Memory Profiler don't display Just-My-Code correctly.

  • XAML メモリ プロファイラーでは、マネージド ヒープ データが正しく表示されません。The XAML Memory Profiler doesn't accurately display managed heap data.

  • CPU プロファイラーでは、モジュールが正しく識別されず、プレフィックス付きの関数名が表示されます。The CPU Profiler doesn't correctly identify modules, and displays prefixed function names.

単体テスト ライブラリ プロジェクトUnit Test Library projects

.NET ネイティブの Windows ストア アプリ プロジェクトの単体テスト ライブラリを有効にするはサポートされていませんし、プロジェクトはビルドに失敗します。Enabling .NET Native on a Unit Test Library for a Windows Store apps project isn't supported and causes the project to fail to build.

関連項目See Also

はじめにGetting Started
ランタイム ディレクティブ (rd.xml) 構成ファイル リファレンスRuntime Directives (rd.xml) Configuration File Reference
.NET Windows ストア アプリの概要.NET For Windows Store apps overview
Windows ストア アプリおよび Windows ランタイムのための .NET Framework サポート.NET Framework Support for Windows Store Apps and Windows Runtime