Windowsランタイム 型システムとCLRの相互作用

Windows 8のリリースにより、開発者は新しいクラスライブラリであるWindowsランタイムにアクセスできます。 WinRTコンポーネントは、Windowsストアおよびデスクトップアプリケーションで使用できます 。 アンマネージC / C ++コード、JavaScript、C＃およびVisual Basicで。

Windowsランタイムメタデータ

内部的に、WinRTコンポーネントはCOM（コンポーネントオブジェクトモデル）コンポーネントであり、メタデータを使用してAPIを記述するようになりました。 このメタデータは、* .winmd拡張子のファイルに保存され、 ECMA-335標準のセクション2（メタデータの定義とセマンティクス）のルールに従ってエンコードされた.NETメタデータの更新バージョンを表します。 通常の.NET Frameworkアセンブリは同じ標準を使用してエンコードされるため、これらのファイルの内容を表示するには、使い慣れたツール（ ildasm.exe 、Object Browserなど）を使用できることを示唆しています。

ほとんどの場合、 ildasm.exeユーティリティでWinMDファイルを表示することは、標準のマネージアセンブリを表示することに非常に似ています。 目に見えるいくつかの違いがあります-主にWinMDファイルには一般に、中間言語（IL）命令が含まれていません。 代わりに、これらのファイルはWindowsランタイムによって提供されるAPIを記述しています。 これらのインターフェイスの実装は、それらの定義から完全に分離することができ、実際には、マシンコードで記述することができます。 ただし、マネージアプリケーションの開発者にとっては、マネージコードが呼び出すAPI定義のみを参照する必要があるため、WinRT APIの実装の詳細は無関係です。 舞台裏では、共通言語ランタイム（CLR）とWindowsオペレーティングシステムがAPI定義とその実装を接続します。



たとえば、Windows.Foundation.winmdメタデータファイル（％WinDir％\ System32 \ WinMetadataディレクトリにあります）では、次の種類のWindows.Foundation.Collections.PropertySetを見つけることができます。このコンストラクターには、本体が含まれていません。







ただし、このタイプを記述するメタデータにより、クラスコンストラクターが呼び出されたときにCLRが実装インスタンスを取得できます。

Windowsランタイムメタデータを表示すると、型とアセンブリの定義で新しいWindowsRuntimeキーワードが使用されていることにも気付くことができます。







このキーワードはコンテキスト依存であり、使用場所によって解釈が異なります。 たとえば、型定義（TypeDef）がキーワードでマークされている場合、この型はWindowsランタイム型システムの規則に従い、この型の呼び出しはWinRT APIの呼び出しと見なされる必要があります。

WinRTコンポーネントとCLRの相互作用

CRLは、 ランタイム呼び出し可能ラッパー（RCW）およびCOM呼び出し可能ラッパー（CCW）ラッパーを介したCOMコンポーネントとの対話をサポートします。 したがって、CLRでは、WinRTオブジェクトへのリンクはRCWへのリンクであり、 RCWにはWinRTオブジェクトへのリンクが含まれています。 したがって、マネージコードは、基本的にコードとWinRTオブジェクト間のインターフェイスであるRCWとやり取りします。







同様に、Windowsランタイムでは、CLRオブジェクトへのリンクはCCWへのリンクであり、 CCWにはCLRオブジェクトへのリンクが含まれています。 WindowsランタイムはCCWと対話して、管理対象エンティティの機能にアクセスします。

WinRTの種類とマネージコード

Windowsランタイム型システムはCLR型システムに似ていますが、WinMDファイルを注意深く見ると、API定義で使用されている型の一部がマネージコードで使用されている型と一致しないことがわかります。 .NET開発者が使い慣れたテクノロジを使用してアプリケーションを作成できるように、CLRはいくつかの種類のWinRTを隠し、他の種類のWinRTへのアクセスを提供しています。 一般に、Windowsランタイムには3種類のタイプがあり、それらの一部はマネージコードでは異なって見えます。

• マネージアセンブリと同じELEMENT_TYPE列挙を使用してメタデータにエンコードされる主要なデータ型 。 例外はSByteタイプで、WinRTではサポートされていません。
• 投影型（マップされた型） 。WinMDファイルでは1つの型としてエンコードされますが、マネージコードでは.NETに相当するものとして表示されます。 たとえば、CLRがメタデータでWindows.Foundation.Uriを読み取る場合、代わりにSystem.Uri型を使用します。 つまり、CLRはWinRT型を隠し、別の型を介してWinRT型へのアクセスを提供します。 さらに、CLRはマネージコードとアンマネージコードの間で型をマーシャリングするため、 System.UriオブジェクトをWindows.Foundation.UriとしてWindowsランタイムに転送できます。 CLRがFCLタイプに投影するWinRTタイプの完全なリストは、 ここにあります 。
• 他のすべてのタイプ 。 WinRT APIタイプの大部分は、そのまま.NET開発者に提供されます。 たとえば、 Windows.UI.Xaml.Controls.Buttonクラスを使用する場合、CLRはこのタイプの特別なビューまたはマーシャリングを提供しません。 CLRが拡張メソッドを提供するタイプもこのカテゴリに含まれます。 たとえば、 System.IO.Streamから派生した型を必要とする.NET FrameworkクラスでWindows.Storage.IInputStreamのWinRTインターフェイスを実装するオブジェクトを使用するには、SystemアセンブリのSystem.IO.WindowsRuntimeStreamExtensionsクラスで定義されている拡張メソッドを使用する必要があります。 Runtime.windowsruntime.dll。

興味深いことに、Windowsメタデータエンコーディングの重要ではない場所に表示される型の小さなカテゴリがまだあります。 これらは、WinRT型を記述するためにのみ使用される.NET Framework型です。 たとえば、Windowsランタイムデリゲートは基本型System.MulticastDelegateでエンコードされますが、これはすべてのWindowsランタイムデリゲートがマネージコードから派生することを意味しません。 代わりに、基本型はメタデータトークンとして単に使用され、型がデリゲート型であることを示します。

タイプ投影

CLRがWinRTタイプを投影（表示）するとき、2つの操作を実行します。

• CLRは、Windowsランタイムタイプをパブリックではなくプライベートとして定義します。 これにより、ソースタイプがマネージコードから見えなくなります。 つまり マネージコードに関しては、存在する唯一の型は.NET Framework型であり、マッピングのターゲットです。
• ソースタイプへのすべての参照は、ターゲット.NET Frameworkタイプへの参照に変換されます。

したがって、CLRはIVector <T>インターフェイスをIList <T>として表します 。IVector<T> CLRの型定義は、パブリックスコープではなくプライベートスコープを持つ型定義と見なされます。 同様に、IVector <UIElement>を実装するWindows.UI.Xaml.Controls.UIElementCollectionタイプは、CLRによって更新されます。 IVector <T>インターフェイスの実装はIList <T>にリダイレクトされるため、マネージコードのUIElementCollectionはIList <UIElement>インターフェイスを実装します。

通常、 ildasm.exeは、リダイレクトを含めずにWinMDファイルの生の表現を表示します。 リダイレクトを有効にしてWinMDファイルの内容を表示するには、/ projectオプションを指定する必要があります。 このオプションを使用すると、CLRがディスク上のメタデータを表示する方法を確認できます。

ベースタイプ

WinRTコンポーネントには共通の基本クラスはありませんが、すべてのWindowsランタイムクラスはIInspectableインターフェイスを実装する必要があり、これはIUnknownインターフェイスを継承します（これは驚くべきことではありません）。 ただし、.NET開発者にとって、すべてのWinRT型はSystem.Objectから派生した型のように見えるため、 EqualsやGetHashCodeなどのメソッドを継承します。 これは、CLRが実行時にオブジェクトをマーシャリングしてWinRTビューと.NETビュー間で型を変換するために可能になりました。

構造

WinRT構造体は、重要なCLR型とは異なり、基本型の1つのオープンフィールドのみを含むことができ、または別のWinRT構造体にすることができます。 したがって、次のコードはコンパイル段階でエラーをスローします。

public struct MyStruct { // 'MyStruct' contains non-public field 'MyStruct.i'. // Windows Runtime structures can contain only public fields. private Int32 i; //Windows Runtime structures can contain only fields. public MyStruct(Int32 i) { this.i = i; } //Windows Runtime structures can contain only fields. public void MyFunc() { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、WinRT構造体は、コンストラクターを定義したり、ヘルパーメソッドを含めることはできません。 ただし、便宜上、一部のCLR構造は独自に投影されるため、開発者にヘルパーメソッドとコンストラクターが提供されます。 これらには、たとえば、 Windows.Foundation.Point 、 Windows.Foundation.Size、およびWindows.Foundation.Rectの構造が含まれます。

行

WinRTのSystem.String型はHSTRINGとして表されます 。 Windowsランタイムメソッドを呼び出すと、CLRはメソッドを呼び出す前に.NET Framework文字列をHSTRINGに変換します。 同様に、CLRは、ランタイムメソッドから返された行をSystem.String型に変換します 。 別の機能があります-WinRT型システムでは、文字列をnullにすることはできません。 nullの代わりに、 String.Emptyを使用して空の文字列を渡す必要があります。 nullを文字列としてWinRT関数に渡そうとすると、CLRはArgumentNullExceptionをスローします。 同様に、WinRT関数がnull文字列を返すことは決してありません。空文字列のみです。

ヌル互換タイプ

WinRT APIは、 Windows.Foundation.IReference <T>インターフェイスを使用してnull互換の重要な型を定義します。これは、CLRが独自のSystem.Nullable <T>に投影します。 たとえば、WinMDファイルのメソッドに次のシグネチャがある場合：

 IReference<bool> Method(IReference<int> i);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マネージコードでは、このメソッドは次のようになります。

 Nullable<bool> Method(Nullable<int> i);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

代表者

WinRTをパラメータータイプまたはデリゲートの戻り値として使用できるのは、WinRT互換タイプのみです。 また、グローバル（パブリック）スコープを持つデリゲートをネストとして宣言することはできません（実際、これらはWindowsランタイム全体の一般的な規則です）。 デリゲートオブジェクトをWindowsランタイムコンポーネントに渡すと、このオブジェクトはCCWラッパーにラップされます。CCWラッパーは、使用するコンポーネントによって解放されるまで、ガベージコレクターによって破棄されません。 もう1つの興味深い事実は、WinRTデリゲートにBeginInvokeメソッドとEndInvokeメソッドがないことです。

イベント

WinRTコンポーネントは、WinRTデリゲートタイプのみを使用してイベントを定義できます。 CLRが.NET Framework System.EventHandler <TEventArgs>デリゲート型にマップするWindows.Foundation.EventHandler <T>デリゲート型があります。 イベントメンバーを定義する場合：

 public event EventHandler<RoutedEventArgs> MyEvent;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、このコード行をコンパイルするときに、コンパイラーは次の命令に変換します。

 private EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> MyEvent; public EventRegistrationToken add_MyEvent(EventHandler<RoutedEventArgs> handler) { return EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .AddEventHandler(handler); } public void remove_MyEvent(EventRegistrationToken token) { EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .RemoveEventHandler(token); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前と同様に、コンパイラは、プライベートフィールドと、イベントの登録とサブスクライブ解除のための2つのアクセサメソッドを作成します。 ただし、これらのメソッドのフィールドとコンテンツのタイプは、これまで使用していたもの（ Delegate.CombineおよびDelegate.Remove ）とは異なります。 一般化されたクラスEventRegistrationTokenTable <T>はフィールドタイプとして使用され、そのタイプ引数は対応するデリゲートタイプです。 このクラスは、イベントハンドラーを表すデリゲートのチェーンを格納します。 新しいハンドラーを追加すると、 EventRegistrationTokenトークンが返されます 。これは 、後でイベントハンドラーを削除するために使用できます。

 public void RaiseEvent() { var list = EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .InvocationList; if (list != null) list(this, new RoutedEventArgs()); } public void Main() { var myClass = new MyClass(); var token = myClass.add_MyEvent(Handler); myClass.RaiseEvent(); myClass.remove_MyEvent(token); myClass.RaiseEvent(); } private void Handler(object sender, RoutedEventArgs args) { Debug.WriteLine("event handling"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イベントを発生させるには、 InvocationListプロパティを使用します。このプロパティは、イベントハンドラーとして追加されたすべてのデリゲートを呼び出しリストに含むデリゲートを返します。

日時

WinRTでは、時刻と日付はWindows.Foundation.DateTime構造体によってUTCで表されます。 CLRは、この型をSystem.DateTimeではなくSystem.DateTimeOffset構造体にマップします。 DateTimeにはタイムゾーン情報が含まれていないことに注意してください。 したがって、WinRT関数によってUTC形式で返される日付と時刻は、CLRによってローカル時刻に変換されます。 逆に、 DateTimeOffset構造体をWinRT関数に渡すと、日付と時刻はUTC形式に変換されます。

配列

WinRT APIは1次元配列のみをサポートします。 したがって、次のコードではコンパイル時エラーが発生します。

 // Arrays in Windows Runtime method signatures must be one dimensional. public int[,] MyFunc() { return new int[5, 5]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マネージコードでは、配列は参照によって渡され、配列の要素への変更は、この配列のインスタンスへのリンクを持つすべてのコードに表示されます。 ただし、WinRTの場合、配列の内容は、APIがSystem.Runtime.InteropServices.InAttributeおよびSystem.Runtime.InteropServices.OutAttributeを使用してその署名で定義する方向にのみマーシャリングされるため、常にそうとは限りません。 どちらの属性もメソッドのパラメーターまたは戻り値に適用され、実行時に管理対象メモリと管理対象外メモリの間でマーシャリングの方向を決定します。 Windowsランタイムでは、パラメーターは読み取り専用[InAttribute]または書き込み専用[OutAttribute]のいずれかであり、[InAttribute]、[OutAttribute]の読み取りと書き込みを同時にマークすることはできません。 つまり、メソッドに渡される配列の内容と配列自体は、読み取りまたは書き込みを行う必要があります。 したがって、[InAttribute]属性でマークされた配列の内容は、呼び出されたメソッドにコピーされるため、メソッドが配列に適用するすべての変更は、呼び出し元のオブジェクトには表示されません。 同様に、[OutAttribute]属性でマークされた配列の内容は、呼び出されたメソッドによって設定され、呼び出し元のオブジェクトにコピーされるため、呼び出されたメソッドは元の配列の内容について仮定しません。

コレクション

コレクションを転送するとき、CLRはコレクションオブジェクトをCCWラッパーにパックし、WinRT APIでコレクションにリンクを渡します。 同時に、ラッパーを介した呼び出しは相互作用の境界を越え、生産性に悪影響を及ぼします。 ただし、配列とは異なり、要素をコピーせずに操作を実行できます。

おわりに

要約すると、CLRの変更により、マネージコード開発者は使い慣れたテクノロジを使用して、新しいWindowsランタイムAPIに簡単に適応できることに注意してください。 この記事では、WinRTとCLRの相互作用の詳細からはほど遠いことを説明しました。 ただし、これは、Windowsランタイムのさらなる調査とより深い理解の基礎を提供できます。