次の方法で共有

  • [アーティクル]

この記事は機械翻訳されたものです。

Windows ランタイムと CLR

.NET と Windows の内部 (機械翻訳)

Shawn Farkas

 

Windows ランタイム (WinRT) 大規模な一連の新しい Api 開発者が Windows エクスペリエンスを提供します。 ちょうど別のクラス ライブラリいたようどの船舶 Windows 8 でマイクロソフト .NET フレームワーク 4.5 の一部として有効に作成する開発者は CLR 4.5 自然な方法で Api を使用するコードを管理しました。 それらにちょうど標準的なマネージ API として呼び出します Api を定義します。 Windows のメタデータ (WinMD) ファイルへの参照を追加できます。 Visual Studio は、自動的に組み込みのあなたのアプリは、単にこの新しい API を使用して開始できるように、新しい Windows UI プロジェクト WinRT Api への参照を追加します。

ボンネットの下に、CLR はマネージ コードを WinMD ファイルと Windows のランタイムとマネージ コード間の遷移を消費するインフラストラクチャを提供します。 この記事では、これらの詳細のいくつかを紹介します。 あなたは離れて WinRT API のマネージ プログラムを呼び出す時に舞台裏で生じる理解と来るでしょう。

マネージ コードからの WinMD ファイルを消費

ECMA-335 で説明されているファイル形式を使用してエンコードされて、WinMD ファイルに定義されて WinRT Api (bit.ly/sLILI)。 共通のエンコード、WinMD ファイルと .NET Framework アセンブリを共有しますが、彼らは同じのではないです。 メタデータの主な違いの 1 つは、WinRT 型システム、.NET 型システムの独立したという事実から生じています。

C# コンパイラや Visual Studio などのプログラムは、CLR メタデータ (IMetaDataImport) などの Api を使用して、.NET Framework アセンブリのメタデータを読み取ると今のメタデータと同様に WinMD ファイルから読むことができます。 メタデータを .NET アセンブリとして同じが丁度するため、CLR メタデータ リーダーと読まれて WinMD ファイルとメタデータ Api アダプターを挿入します。 これは、WinMD ファイルは、.NET アセンブリのように読むことができます (を参照してください図 1)。

The CLR Inserts a Metadata Adapter Between WinMD Files and the Public Metadata Interface
図 1 CLR メタデータ アダプター WinMD ファイルとパブリック メタデータ インターフェイスの間を挿入します。

ILDasm を実行して CLR メタデータ アダプター上の WinMD ファイルを実行する変更を理解することができます。 既定では、ILDasm CLR メタデータ アダプターなしディスクにエンコードとしてそのままの形式で WinMD ファイルの内容を示します。 ただし、あなた ILDasm/project コマンド ライン パラメーターを渡す場合、メタデータ アダプターを可能として CLR メタデータを見ることができるし、マネージ ツールはそれを読みます。

ILDasm 側のコピーを実行する — 1/project パラメーターと 1 つなし — CLR メタデータ アダプター WinMD ファイルへの変更を容易に探索できます。

Windows のランタイムと .NET 型システム

メタデータのアダプターを実行する主要な操作の 1 つは、WinRT と .NET の型システムをマージすることです。 高レベルでは、WinRT 型の 5 つのカテゴリは WinMD ファイルに表示されるし、CLR によって考慮される必要があります。 これらを図 2 に示します。 各カテゴリの詳細を見てみましょう。

図 2 WinRT タイプ WinMD ファイル

Category 例 :
標準 WinRT タイプ Windows.Foundation.Collections.PropertySet Windows.Networking.Sockets.DatagramSocket
プリミティブ型 Byte、Int32、文字列、オブジェクト
投影の種類 Windows.Foundation.Uri Windows.Foundation.DateTime
投影されたインターフェイス Windows.Foundation.Collections.IVector <T> Windows.Foundation.Iclosable
.NET のヘルパーの種類 Windows.Storage.Streams.IInputStream Windows.Foundation.IasyncInfo

標準 WinRT タイプながら、CLR Windows ランタイムによって公開される型の多くのカテゴリーの特別なサポートをしています、WinRT 型の大部分は、CLR によって特別すべてで扱われません。 代わりに、.NET 開発者が変更されていない、これらの型を表示し、彼らは大きなクラス ライブラリとしてを使用 Windows ストアの書き込みを有効にするアプリケーション。

プリミティブ型このプリミティブ型のセットは同じ ELEMENT_TYPE 列挙体を使用して、.NET アセンブリの使用を WinMD ファイルにエンコードされます。 あたかも、相当する .NET CLR は自動的にこれらのプリミティブ型を解釈します。

ほとんどの部分については、WinRT プリミティブ型は .NET プリミティブ型としてちょうど治療に動作します。 例えば、.NET では、CLR WinRT DWORD として .NET System.Int32 トラブルなく扱うことができるよう 32 ビット整数が Windows ランタイムで同じビット パターンを持っています。 しかし、2 つの注目すべき例外は、文字列とオブジェクトです。

Windows のランタイムでは、HSTRING データ型は、.NET System.String と同じではない文字列が表されます。 同様に、IInspectable ※ Windows ランタイムを意味間 ELEMENT_TYPE_OBJECT .net、System.Object を意味します。 文字列またはオブジェクトの CLR オブジェクト型の WinRT と .NET の表現の間を変換する実行時にマーシャ リングする必要があります。 このマーシャ リングについては、この記事の後半での動作が表示されます。

投影型同等 WinRT 型システムである既存基礎 .NET 型があります。 たとえば、Windows ランタイム TimeSpan 構造とどちらも .NET Framework の対応する型がある、Uri クラスを定義します。

.NET 開発者がこれらの基本データ型の間に変換をしないようにするには、WinRT バージョンの同等の .NET CLR のプロジェクトします。 これらの予測は効果的に CLR .NET と WinRT 間型のシステム挿入点をマージします。

たとえば、Windows のランタイムのシンジケーション­Client.RetrieveFeedAsync API 取得 WinRT Uri のパラメーターとして。 .NET の開発者はこの API に渡すための新しい Windows.Foundation.Uri インスタンスを手動で作成する必要はなく、CLR プロジェクト型として .NET 開発者できます、System.Uri より精通している、種類使用します。

投影法の別の例は、Windows.Founda です­tion。HResult 構造: System.Exception 型を CLR によって写し出されます。 .NET では、開発者がエラー HRESULT をだから WinRT API IAsycn などを有するではなく、例外として伝達されるエラー情報を見に使用される­Info.ErrorCode エクスプレス エラー情報として HResult 構造が自然に感じることはありません。 代わりに、CLR プロジェクトは HResult を例外は、IAsyncInfo.ErrorCode などの WinRT API を .NET 開発者にとってより使いやすくなります。 ここ Windows.winmd でエンコードされた IAsyncInfo の ErrorCode プロパティの例です：

.class interface public windowsruntime IAsyncInfo
{
  .method public abstract virtual
    instance valuetype Windows.Foundation.HResult
    get_ErrorCode()
}

ここにある IAsyncInfo ErrorCode プロパティは CLR の投影後。

 

.class interface public windowsruntime IAsyncInfo
{
 .method public abstract virtual
   instance class [System.Runtime]System.Exception
   get_ErrorCode()
}

インターフェイスを投影に相当する .NET の基本的なインターフェイスのセットをまた提供します、Windows ランタイム。 CLR 型予測は、同様に、これらのインターフェイスの型システムでこれらの基本的なポイントを再びマージを実行します。

WinRT コレクション インターフェイスの IVector <T> IIterable <T> など予想のインターフェイスの最も一般的な例です。 IMap < K, V >。 .NET を使用する開発者はコレクション インターフェイス IList <T> IEnumerable <T> などに精通しています。 IDictionary < K, V >。 開発者は、同じことを行うタイプの 2 の機能的に同等のセットで対処する必要があるないように CLR プロジェクト コレクションを .NET の同等にインタ フェースし、また、WinRT を非表示に WinRT インターフェイスします。

ときに、型のインターフェイス実装一覧で表示されるときにパラメーターとして表示し、戻り値の型のメソッドのこれらのタイプを投影することに加えて、CLR もこれらのインターフェイス プロジェクトする必要があります。 たとえば、WinRT PropertySet 型 WinRT IMap < オブジェクト、文字列 > を実装します。 インターフェイス。 CLR は、ただし、< オブジェクト、文字列 > IDictionary を実装する型として PropertySet を投影します。 この投影法は IMap < オブジェクト、文字列 > を実装に使用される PropertySet のメンバーを実行するとき 非表示になります。 代わりに、.NET 開発者 PropertySet 対応する IDictionary を < オブジェクト、文字列 > アクセスします。 メソッド。 ここで PropertySet の部分的なビュー Windows.winmd でエンコードされた：

.class public windowsruntime PropertySet
  implements IPropertySet,
    class IMap`2<string,object>,
    class IIterable`1<class IKeyValuePair`2<string,object> >
{
  .method public instance uint32 get_Size()
  {
    .override  method instance uint32 class 
      IMap`2<string,object>::get_Size()
  }
}

そしてここ CLR 投影後 PropertySet の部分的なビューです。

.class public windowsruntime PropertySet
  implements IPropertySet,
    class IDictionary`2<string,object>,
    class IEnumerable`1<class KeyValuePair`2<string,object> >
{
  .method private instance uint32 get_Size()
  {
  }
}

3 つのタイプの予測が発生することに注意してください。IMap < オブジェクト、文字列 > IDictionary < オブジェクト、文字列 >, < オブジェクト、文字列 > IKeyValuePair に KeyValuePair < 文字列、オブジェクト > と IIterable <IKeyValuePair> に IEnumerable <KeyValuePair> します。 また、get_Size メソッド IMap からが隠されていると気づきます。

.NET フレームワーク ヘルパーのタイプ 、Windows ランタイムが完全マージは .NET 型システムにポイントを持っていないが、.NET Framework を操作するヘルパー メソッドを提供します。 ほとんどのアプリケーションに十分に重要であるいくつかの種類。 2 つの最高の例は、WinRT ストリームと非同期インタ フェースです。

Windows.Storage.Streams.IRandomAccess プロジェクトのいない、CLR が­ストリーム System.Stream にそれを IRandom 拡張メソッドの集合を提供して­.NET ストリームものとしてこれらの WinRT ストリームを治療することができます AccessStream。 たとえば、.NET StreamReader を持つ WinRT ストリーム OpenStreamForReadAsync 拡張メソッドを呼び出すことによって簡単に読むことができます。

Windows のランタイムは、IAsyncInfo インタ フェースなどの非同期操作を表すインターフェイスのセットを提供します。 .NET フレームワーク 4.5 では、どの開発者 WinRT Api と .NET Api の同じやり方で使用する、非同期の操作を待っているための組み込みサポートがあります。

これを有効にするには、.NET Framework GetAwaiter 拡張メソッドの WinRT 非同期インターフェイスのセット付属しています。 これらのメソッドは、c# および Visual Basic コンパイラによってを待って WinRT 非同期操作を有効にする使用されます。 その例を次に示します。

private async Task<string> ReadFilesync(StorageFolder parentFolder, 
  string fileName)
{
  using (Stream stream = await parentFolder.OpenStreamForReadAsync(fileName))
  using (StreamReader reader = new StreamReader(stream))
  {
    return await reader.ReadToEndAsync();
    }
}

.NET はフレームワーク間の移行および theWindows ランタイム 、CLR WinRT Api をシームレスに呼び出すにはマネージ コードと Windows ランタイム マネージ コードにコールバックするためのメカニズムが提供されます。

それは、WinRT Api を呼び出すための CLR のサポートは、既存の COM 相互運用インフラストラクチャ上に組み込まれている驚きではないその最も低いレベルでは、COM の概念の上に Windows のランタイム構築されています。

WinRT 相互運用機能と COM 相互運用機能の重要な違いの 1 つはどのようにはるかに少ない Windows ランタイムで対処しなければならない構成です。 WinMD ファイルは、すべてのマネージ コードでは、MarshalAs 属性を使用する必要はありません彼らは .NET 型システムへの適切に定義されたマッピングを公開して Api を記述する豊富なメタデータがあります。 同様に、Windows の 8 WinMD のファイルをその WinRT Api の出荷、ため、アプリケーションにバンドルされているプライマリ相互運用機能アセンブリを持っている必要はありません。 代わりに、CLR はすべてそれ WinRT Api を呼び出す方法について知っている必要がありますを把握するボックスで WinMD ファイルを使用します。

これらの WinMD のファイルは実行時にマネージ開発者 Windows ランタイムへのアクセスを許可する使用されるマネージ型定義を提供します。 CLR から WinMD ファイルを読み取る Api にはマネージ コードから簡単に使用する書式設定メソッドの定義が含まれてが、基になる WinRT API 異なる API シグネチャを使用します (アプリケーション バイナリ インターフェイスまたは ABI として呼ば署名)。 API や ABI の署名の間の違いの 1 つの例よう標準 COM WinRT Api は HRESULT を返すし、WinRT API の戻り値を出力パラメーター ABI 署名に実際には、です。 CLR WinRT API については、この記事の後半で呼び出す方法でを見ると、マネージ メソッドのシグネチャは、WinRT ABI 署名に変換する方法の例を紹介します。

ランタイム呼び出し可能ラッパーおよび COM 呼び出し可能ラッパー

CLR WinRT オブジェクトを入力すると、.NET オブジェクトであるかのようそれ呼び出し可能する必要があります。 これを実現するのには、CLR は、ランタイム呼び出し可能ラッパー (RCW) の各 WinRT オブジェクトをラップします。 RCW はマネージ コードが操作して、コードとコードを使用して WinRT オブジェクト間のインターフェイスです。

逆に、Windows のランタイムからのマネージ オブジェクトが使用されるとき、まるで WinRT オブジェクトが呼び出される必要があります。 この場合は Windows ランタイムに送信しているときのマネージ オブジェクト、COM 呼び出し可能ラッパー (CCW) がラップされます。 Windows ランタイム COM として同じインフラストラクチャを使用するため、Ccw をマネージ オブジェクトへのアクセス機能を操作できます (を参照してください図 3)。

Using Wrappers for Windows Runtime and Managed Objects
図 3 Windows ランタイムおよびマネージ オブジェクトのラッパーを使用します。

マーシャ リング スタブ

いくつかのことが発生するは、WinRT 境界など、相互運用の境界を越えてマネージ コードに遷移するときする必要があります。

  1. マネージ入力パラメーターは、WinRT 同等、Ccw をマネージ オブジェクト構築などに変換します。
  2. メソッドで呼び出されている RCW から呼び出される WinRT メソッドを実装するインターフェイスを見つけます。
  3. WinRT メソッドを呼び出します。
  4. 対応するマネージ WinRT 出力パラメーター (戻り値を含む) に変換します。
  5. 任意のエラー HRESULT から WinRT API をマネージ例外に変換します。

これらの操作に、CLR が生成されますあなたのプログラムの代理では、マーシャ リングのスタブが発生します。 RCW でマーシャ リング スタブは、WinRT API に移行する前に、実際にどのようなマネージ コードを呼び出すです。 同様に、Windows ランタイムの呼び出しはマネージ コードに遷移するとき、CCW でマーシャ リング スタブの CLR が生成されるには。

マーシャ リング スタブ Windows ランタイムと .NET Framework のギャップにまたがる橋を提供します。 どのように動作を理解、Windows の実行時にプログラムを呼び出すときに何が起こるかのより深い理解を得るに役立ちます。

次の例

文字列のリストを取得し、各要素間の区切り文字列で連結して WinRT API を想像します。 この API は、マネージ シグネチャなどがあります。

public string Join(IEnumerable<string> list, string separator)

CLR は、メソッドの ABI 署名アウトを把握する必要があります、ABI の定義に従って、メソッドを呼び出す必要があります。 ありがたいことに、明確 API シグネチャを与え、ABI の署名を取得する一連の確定的な変換を適用できます。 最初の変換はメタデータ アダプターはそれをロードする前にでそれ WinMD ファイルで定義されているフォームに、API を返す彼ら WinRT 同等で、投影されたデータの種類を置き換えることです。 この例では、IEnumerable <T> この関数の WinMD ビューを実際にあるので実際に IIterable <T> の投影です。

public string Join(IIterable<string> list, string separator)

WinRT 文字列は、HSTRING でのデータのタイプでは、Windows の実行時、この関数は実際にように見えるように格納されます。

public HSTRING Join(IIterable<HSTRING> list, HSTRING separator)

呼び出しが実際に発生、ABI 層で WinRT Api HRESULT 戻り値があるし、彼らの署名からの戻り値は出力パラメーターです。 さらに、ABI の署名をこのメソッドのようになるオブジェクト ポインターです。

HRESULT Join(__in IIterable<HSTRING>* list, HSTRING separator, __out HSTRING* retval)

WinRT のすべてのメソッドは、オブジェクトによって実装されるインターフェイスの一部でなければなりません。 私たち Join メソッドは、たとえば、StringUtilities クラスによってサポートされている IConcatenation インターフェイスの一部かもしれない。 メソッド呼び出しに結合を行う前に、CLR は通話する IConcatenation インターフェイス ポインターの保持を取得する必要があります。

マーシャ リング スタブの仕事は、RCW 上 WinRT ファイナルコール WinRT インターフェイスへの呼び出しからオリジナルを変換する管理です。 この場合は、マーシャ リング スタブの擬似コードのようになります図 4 （とクリーンアップの呼び出しは明快ためのに省略)。

図 4 CLR から Windows ランタイムへの呼び出しをマーシャ リング スタブの例

public string Join(IEnumerable<string> list, string separator)
{
  // Convert the managed parameters to WinRT types
  CCW ccwList = GetCCW(list);
  IIterable<HSTRING>* pCcwIterable = ccwList.QueryInterface(IID_IIterable_HSTRING);
  HSTRING hstringSeparator = StringToHString(separator);
  // The object that managed code calls is actually an RCW
  RCW rcw = this;
  // You need to find the WinRT interface pointer for IConcatenation
  // implemented by the RCW in order to call its Join method
  IConcatination* pConcat = null;
  HRESULT hrQI = rcw.QueryInterface(IID_ IConcatenation, out pConcat);
  if (FAILED(hrQI))
    {
      // Most frequently this is an InvalidCastException due to the WinRT
      // object returning E_NOINTERFACE for the interface that contains
      // the method you're trying to call
      Exception qiError = GetExceptionForHR(hrQI);
      throw qiError;
    }
    // Call the real Join method
    HSTRING returnValue;
    HRESULT hrCall = pConcat->Join(pCcwIterable, hstringSeparator, &returnValue);
    // If the WinRT method fails, convert that failure to an exception
    if (FAILED(hrCall))
    {
      Exception callError = GetExceptionForHR(hrCall);
      throw callError;
    }
    // Convert the output parameters from WinRT types to .NET types
    return HStringToString(returnValue);
}

この例ではマネージ パラメーターがマネージ表現からその WinRT 形式に変換する最初のステップです。 この場合、コードは list パラメーターの CCW を作成します、System.String パラメーターを HSTRING に変換します。

次のステップは、ジョインの実装を供給 WinRT インターフェイスを見つけることです。 これと呼ばれるマネージ コードに参加に RCW でラップ WinRT オブジェクトの QueryInterface 呼び出しを発行することによって発生します。 InvalidCastException WinRT メソッド呼び出しからスローを取得最も一般的な理由は、この QueryInterface 呼び出しが失敗したかどうかです。 これが起こることができる 1 つの理由は、WinRT オブジェクトが、呼び出し元はそれを期待するすべてのインターフェイスを実装しないことです。

実際の行動が今 — 戻り値 HSTRING を実際には論理を格納するための場所を提供する WinRT Join メソッドを呼び出す相互運用スタブになります。 WinRT メソッドが失敗した場合は、これは相互運用スタブは例外に変換し、スロー HRESULT の失敗を示します。 つまり、マネージ コード WinRT メソッド呼び出しからスローされている例外を検出した場合、呼び出される WinRT メソッドがエラーを返す可能性が高いです HRESULT と CLR その障害状態をコードを示す例外を投げた。

最後のステップは出力パラメーターから、WinRT 表現を .NET 形式に変換することです。 この例では、論理値は、結合呼び出しの出力パラメーターからは HSTRING .NET 文字列に変換する必要があります返します。 この値は、[スタブの結果として返されることができます。

Windows ランタイムからマネージ コードへの呼び出し

Windows ランタイムとターゲットから発信された呼び出しコード作業は同様の方法で管理。 CLR の Windows ランタイム コンポーネントそれに対して持つ相互運用スタブ メソッドが満ちている仮想関数テーブルを持つインターフェイスで QueryInterface 呼び出しに応答します。 これらのスタブは、私は以前、しかし、逆方向を示したものと同じ機能を実行します。

この時間と仮定を除いてそれがマネージ コードでの実装しに Windows ランタイム コンポーネントから呼び出されているもう一度、参加 API の場合を考えてみましょう。 この遷移を発生することができますスタブの擬似コードのように見えるかもしれませんが図 5。

図 5 Windows ランタイムから発信する、CLR のマーシャ リング スタブの例

HRESULT Join(__in IIterable<HSTRING>* list, 
  HSTRING separator, __out HSTRING* retval)
{
  *retval = null;
  // The object that native code is calling is actually a CCW
  CCW ccw = GetCCWFromComPointer(this);
  // Convert the WinRT parameters to managed types
  RCW rcwList = GetRCW(list);
  IEnumerable<string> managedList = (IEnumerable<string>)rcwList;
  string managedSeparator = HStringToString(separator);
  string result;
  try
  {
    // Call the managed Join implementation
    result = ccw.Join(managedList, managedSeparator);
  }
  catch (Exception e)
  {
    // The managed implementation threw an exception -
    // return that as a failure HRESULT
    return GetHRForException(e);
  }
  // Convert the output value from a managed type to a WinRT type
  *retval = StringToHSTring(result);
  return S_OK;
}

まず、このコードの入力パラメーター、WinRT データ型からマネージ型に変換します。 入力リストが WinRT オブジェクトであると仮定すると、スタブは、それを使用するマネージ コードを許可するには、そのオブジェクトを表す RCW を得なければなりません。 文字列値は、単に、HSTRING からは System.String に変換されます。

次に、Join メソッドで、反時計回りのマネージ実装に呼び出しが行われる このメソッドが例外をスローする場合、相互運用スタブはそれをキャッチし、WinRT 呼び出し元に返される HRESULT エラーに変換します。 これは、なぜ Windows ランタイム コンポーネントによってと呼ばれるマネージ コードからスローされるいくつかの例外は、プロセス クラッシュしないについて説明します。 Windows のランタイム コンポーネントが失敗を示す HRESULT を処理する場合は、効果的にキャッチとスローされる例外の処理と同じです。

最後のステップは、WinRT の同等データ型をこの場合は、System.String は HSTRING に変換する .NET データ型から出力パラメーターを変換します。 戻り値は、出力パラメーターと HRESULT が返される成功にそれから置かれます。

投影されたインターフェイス

以前、CLR いくつか WinRT インターフェイスと同等の .NET インターフェイスにプロジェクトしますが. たとえば、IMap < K, V > IDictionary < K, V > が投影されます。 つまり WinRT マップと .NET 辞書アクセス可能です。 この投影作業するを有効にするには、WinRT インターフェイスそれ、そして逆に投影され、.NET インターフェイスを実装するスタブの別のセットが必要です。 たとえば、IDictionary < K, V > < K, V > IMap は、TryGetValue メソッドを持つ このメソッドが含まれていません。 TryGetValue を使用するマネージ呼び出し元を許可するには、CLR は IMap を持ってメソッドの面でこのメソッドを実装するスタブを提供します。 これと同様に見えるかもしれませんが図 6。

図 6 IDictionary IMap の面での概念の実装

bool TryGetValue(K key, out V value)
{
  // "this" is the IMap RCW
  IMap<K,V> rcw = this;
  // IMap provides a HasKey and Lookup function, so you can
  // implement TryGetValue in terms of those functions
  if (!rcw.HasKey(key))
    return false;
  value = rcw.Lookup(key);
  return true;
}

その作業を行うには、この変換スタブいくつかの呼び出しを基底の IMap 実装になります。 たとえば、Windows.Foundation.Collections.PropertySet オブジェクトにキー"NYJ"が含まれているかどうかを確認するマネージ コードの次のビットを書いたとします。

 

object value;
if (propertySet.TryGetValue("NYJ", out value))
{
  // ...
}

TryGetValue 呼び出しプロパティ セット キーが含まれているかどうかが決まりますが、コール スタックように見える可能性があります図 7。

TryGetValue コールのコール スタックは図 7

スタック Description
PropertySet::HasKey WinRT PropertySet 実装
HasKey_Stub 辞書スタブの HasKey 呼び出し、WinRT 呼び出しに変換するスタブ マーシャ リング
TryGetValue_Stub IMap の面で IDictionary を実装するスタブします。
Application マネージ アプリケーションのコードの PropertySet.TryGetValue を呼び出す

ラッピングする

CLR のサポート for Windows のランタイム マネージ開発者は、彼らが標準の .NET アセンブリで定義されたマネージ Api を呼び出すことができますように簡単に WinMD ファイルで定義されている WinRT Api を呼び出すことができます。 ボンネットの下に、CLR メタデータ アダプター WinRT 型システム、.NET 型システムとマージに役立つ予測を実行します。 それも相互運用スタブのセットを使用して .NET コード WinRT メソッドを呼び出すことを許可して、その逆。 一緒に取られて、これらのテクニックを Windows ストア アプリケーションから WinRT Api を呼び出すマネージ コードの開発者のためやすくなります。

Shawn Farkas CLR では、10 年間働いてきた、現在開発リード CLR Windows ランタイム投影と .NET の相互運用を担当。Microsoft .NET Framework 4.5 の前に彼は、CLR セキュリティ モデルを働いた.彼のブログで見つけることができます blogs.msdn.com/shawnfa。

この記事のレビュー、次技術専門家のおかげで。ライアン バイントン、レイラ ・ ドリスコール、Yi zhang さん