管理、株主、または過度に野心的な開発者の希望を示しています。Microsoft .NET 共通言語ランタイム (CLR) で®マネージド コードとして記述されたすべてのソフトウェアを実行することは単に不可能です。 プログラミング能力が不足しているため、多くの組織が、新しいランタイムがどれほど魅力的であっても、既存の Win32® ベース、C、C++、Visual Basic® 6.0 ベース、または COM コードベースの 100% を書き換える可能性は低いです。 つまり、.NET 時代以前に記述されたネイティブ コードの世界は、.NET で記述された新しいマネージド コンポーネントと平和的に共存する必要があります。NET に対応した言語。 幸いなことに、CLR は、過度の痛みや苦しみなしに、2 つの世界を橋渡しすることをサポートしています。
      ネイティブ コードとマネージド コードを共存させるためには、CLR (MSCOREE.DLL) 内で実行されるマネージド コードを、MSCOREE.DLLの外部で実行されているコードと統合できるようにするためのメカニズムがいくつか必要です。 つまり、マネージド プログラムは、従来の COM または Win32 ベースのコードを実行するのに十分な長さである "アンマネージド モード" で実行する必要があります。 また、アンマネージ スレッドは、マネージド型でメソッドを呼び出すことができるのに十分な長さMSCOREE.DLLにアクセスする必要があります。


図 1マネージド コードとアンマネージド コードの統合

      幸いにも、CLR は両方の種類の遷移をサポートしているため、マネージド DLL とネイティブ DLL の両方を 1 つのプロセスで共存させ、CLR 内でホストされているかどうかに関係なく、DLL 間で呼び出しを行うことができます。 一般的な 2001 年頃のプロセスの例を図 1示します。 一部のコードはMSCOREE.DLL内で実行され、一部は実行されないことに注意してください。 オペレーティング システム全体がマネージド コードで書き換えられる場合を除き、これはしばらくの間問題の状態である可能性があります。現在、基になる Windows® オペレーティング システムは、マネージド DLL ではなくネイティブ DLL を介して公開されます。

P/Invoke

示す 2 つの宣言を指定すると、OLE32Wrapper.CoImpersonateClient1 を呼び出すには、プログラマが手動で結果を確認し、失敗した HRESULT を明示的に処理する必要があります。 TransformSig パラメーターが使用されていたため、OLE32Wrapper.CoImpersonateClient2 を呼び出すと、失敗した HRESULT をプログラマの介入なしに暗黙的に COMException にマップするように CLR に指示します。 OLE32Wrapper.CoImpersonateClient2 の場合、基になる関数から返される値がないため、このメソッドは void を返します。 型指定された値 (double など) を返すようにメソッドが宣言されている場合、P/Invoke レイヤーは、基になるネイティブ関数が参照によって追加のパラメーター (la COM の [retval] 属性) を受け入れると想定していました。 このマッピングは、TransformSig パラメーターが true の場合にのみ行われます。

型指定された画面切り替え

      ランタイムから呼び出す (またはランタイムに) 呼び出すとき、パラメーターは、図 5に示すように、必ず呼び出し履歴に渡されます。 これらのパラメーターは、ランタイムと外部の両方の型のインスタンスです。 相互運用のしくみを理解する鍵は、指定された "値" にマネージド型とアンマネージ型の 2 つの型があることを理解することです。 さらに重要なのは、一部のマネージド型はアンマネージ型に等形です。つまり、その型のインスタンスをランタイムの外部に渡す必要がある場合、変換は必要ありません。 しかし、多くの型は同形ではなく、外部に適した表現を思い付くために何らかの変換が必要です。

のパラメーター
図 5 呼び出し履歴 のパラメーター

      図 6

、この効果を示します。


図 7非同型パラメーター

      MarshalAs 属性を使用して、指定されたパラメーター (または構造体内のフィールド) をマーシャリングする方法を自由に制御できます。 この属性は、MSCOREE 外の世界に表示するアンマネージ型を示します。 少なくとも、MarshalAs 属性を使用して、特定のパラメーターまたはフィールドに対応するネイティブ型を示すことができます。 多くの型では、CLR は適切な既定値を選択します。 ただし、MarshalAs 属性を使用して、これらの既定値をオーバーライドできます。 たとえば、図 8

  using System.Runtime.InteropServices;
[ StructLayout(LayoutKind.Sequential) ]
public struct PERSON_REP {
  [ MarshalAs(UnmanagedType.BStr) ] 
  public String name;
  public double age;
  [ MarshalAs(UnmanagedType.VariantBool) ]
  bool dead;
}

  struct PERSON_REP {
  BSTR name;
    public double age;
    VARIANT_BOOL dead;
  };

に示すように、CLR オブジェクトへの参照が MSCOREE 境界を越えてマーシャリングされると、CLR オブジェクトへのプロキシとして機能する COM 呼び出し可能ラッパー (CCW) が作成されます。 同様に、COM オブジェクトへの参照が MSCOREE 境界を介してマーシャリングされると、ランタイム呼び出し可能ラッパー (RCW) が作成され、COM オブジェクトへのプロキシとして機能します。 どちらの場合も、"proxy" は基になるオブジェクトのすべてのインターフェイスを実装します。 さらに、"プロキシ" は、IDispatch、オブジェクトの永続化、イベントなどの COM および CLR イディオムを、他のテクノロジの対応するコンストラクトにマップしようとします。


図 9RCW および CCW アーキテクチャ

      RCW または CCW を介して MSCOREE 境界をまたぐインターフェイスの場合、CLR はマネージド インターフェイス定義への一連の注釈に依存して、型を変換する方法に関する基になるマーシャリング レイヤー ヒントを提供します。 これらのヒントは、P/Invoke で説明したヒントのスーパーセットです。 定義する必要があるその他の側面としては、UUID、vtable と dispatch、デュアル マッピング、IDispatch の処理方法、配列の変換方法などがあります。 これらの側面は、System.Runtime.InteropServices 名前空間の属性を使用して、マネージド インターフェイス定義に追加されます。 これらの属性がない場合、CLR は、特定のインターフェイスとメソッドの既定の設定を慎重に推測します。 ゼロから定義された新しいマネージド インターフェイスの場合、共通言語ランタイムの外部でインターフェイスを使用する場合は、属性を明示的に使用すると便利です。

TLBIMP と TLBEXP

      ネイティブ COM 型定義 (構造体、インターフェイスなど) を CLR に手動で変換できます。特に正確な TLB が使用できない場合は、これが必要な場合があります。 CLR でのリフレクションのユビキタスを考えると、型定義を逆の方向に変換する方が簡単ですが、やはり、手動翻訳に頼るよりもツールを使用することをお勧めします。 CLR には、COM TLB が十分に正確である限り、この翻訳を行う妥当な作業を行うコードが付属しています。 System.Runtime.InteropServices.TypeLibConverter は、TLB アセンブリと CLR アセンブリ間で変換できます。 ConvertAssemblyToTypeLib メソッドは CLR アセンブリを読み取り、対応する COM 型定義を含む TLB を出力します。 この変換プロセスのヒント (MarshalA など) は、ソース型のインターフェイス、メソッド、フィールド、およびパラメーターにカスタム属性として表示される必要があります。 ConvertTypeLibToAssembly メソッドは COM TLB を読み取り、対応する CLR 型定義を含む CLR アセンブリを出力します。 SDK には、NMAKE での使用に適したコマンド ライン インターフェイスの背後にこれら 2 つの呼び出しをラップする 2 つのツール (TLBIMP.EXEとTLBEXP.EXE) が付属しています。 これらのツール間の関係を図 10

示します。


図 10TLBIMP と TLBEXP

      一般に、最初に CLR ベースの言語で型を定義してから、TLB を出力する方が簡単です。 たとえば、図 11

、ソース コードが CLR 前言語 (Visual Basic 6.0 など) から CLR 対応言語 (Visual Basic.NET や C# など) に機械的に変換される部分ポート アプローチを示しています。 この方法は、相互運用サービスを使用して、下位のネイティブ ライブラリを CLR にインポートできるという事実に依存します。


図 14 部分ソース コード移植 を使用した .NET の

      図 15 は、ネイティブ サブコンポーネントに依存せずに CLR 対応言語でソース コードを完全に書き換える完全なポート アプローチを示しています。 この方法は、下位のネイティブ ライブラリのマネージド バージョンの存在に依存します。 また、マネージド ライブラリが要求するスタイルの違いにソース コードを適応させる意欲にも依存します。 このアプローチでは最も労力が必要ですが、相互運用の移行が少なくなるだけでなく、(通常は) より豊富で優れた設計のライブラリという利点があります。


図 15 完全なソース コード 移植 を使用した .NET の

      図 16 は、ソース コードを単独で残し、相互運用サービスを使用してコードを CLR にインポートする "punt" アプローチを示しています。 この方法は、下位のネイティブ ライブラリのマネージド バージョンの存在に依存せず、開発者がソース コードを重要な方法で適応させる必要もありません。 この方法では、必要な労力が最も少なく、メソッドごとの下位ライブラリ呼び出しの比率が高いため、相互運用の遷移が少なくなるという利点があります。


図 16 バイナリ インポートを使用した .NET の(Punt アプローチ)

      XML や SOAP などのテクノロジはいつでも使用できますが、CLR では、COM と Win32 の古い世界から C# と Web サービスの新しい世界に移行するためのさまざまな選択肢が開発者に提供されます。

Don to housecom@microsoft.comの質問とコメントを送信します。