プラットフォーム呼び出しサービス

プラットフォーム呼び出しサービス(一般にP/Invokeと呼ばれます) は、マネージド コードがネイティブ コードを呼び出すことを可能にする、Microsoftの共通言語ランタイムなどの共通言語インフラストラクチャ実装の機能です。

C# や VB.NET などのマネージ コードは、.NET Framework を構成するライブラリ内で定義されているクラス、メソッド、および型へのネイティブ アクセスを提供します。.NET Framework は広範な機能を提供しますが、通常はアンマネージ コードで記述される多くの低レベルのオペレーティング システム ライブラリや、同じくアンマネージ コードで記述されるサード パーティ ライブラリにアクセスできない場合があります。P/Invoke は、プログラマがこれらのライブラリの関数にアクセスするために使用できる手法です。これらのライブラリ内の関数の呼び出しは、マネージ コード内でアンマネージ関数のシグネチャを宣言することによって行われます。このシグネチャは、他のマネージ メソッドと同様に呼び出すことができる実際の関数として機能します。宣言はライブラリのファイル パスを参照し、共通言語ランタイム (CLR) によってアンマネージ型との間で暗黙的にマーシャリングされる可能性が最も高いマネージ型で関数のパラメーターと戻り値を定義します。アンマネージ データ型が複雑になりすぎて、マネージ型との間で単純な暗黙的な変換が行えなくなった場合、フレームワークでは、関数、戻り値、および/またはパラメーターの属性を定義して、暗黙的に変換しようとして例外が発生しないように、データをマーシャリングする方法を明示的に調整できます。

マネージ コード プログラマーには、アンマネージ言語でのプログラミングに比べて、低レベルのプログラミング概念の抽象化が数多くあります。そのため、マネージ コードの経験しかないプログラマーは、P/Invoke を使用する際の障害の一部を克服するために、ポインター、構造体、参照渡しなどのプログラミング概念を復習する必要があります。

現在使用されている P/Invoke の 2 つのバリエーションは次のとおりです。

• ネイティブコードはダイナミックリンクライブラリ（DLL）経由でインポートされます
• 呼び出し元のアセンブリに埋め込まれたメタデータは、ネイティブ コードの呼び出し方法とデータへのアクセス方法を定義します (通常、コンパイラがマーシャル グルーを生成するために属性付きソース指定子が必要です)
  • この定義は「明示的」な部分である

• C++/CLI を使用すると、アプリケーションは明示的な宣言なしに、マネージド ヒープ (ポインターを追跡することによって) と任意のネイティブ メモリ領域を同時に使用できます。(暗黙的)
• この場合の主な利点は、基礎となるネイティブ データ構造が変更された場合でも、命名に互換性がある限り、互換性を損なう変更が回避されることです。
  • つまり、ネイティブ ヘッダー内の構造体の追加、削除、並べ替えは、構造体のメンバー名も変更されていない限り、透過的にサポートされます。

P/Invoke を使用する場合、CLR はDLL の読み込みと、以前のアンマネージ型からCTS型への変換 (パラメーター マーシャリングとも呼ばれます) を処理します。^{[1] [引用が必要]}これを実行するために、CLR は次の処理を実行します。

• 関数を含むDLLを見つけます。
• DLL をメモリにロードします。
• メモリ内の関数のアドレスを特定し、その引数をスタックにプッシュし、必要に応じてデータをマーシャリングします。

P/Invoke は、標準 (アンマネージ) CまたはC++ DLL を使用するときに便利です。Windowsライブラリによって提供される多くの関数には利用可能なラッパーがないため、プログラマが広範なWindows APIにアクセスする必要がある場合に使用できます。Win32 APIが.NET Frameworkによって公開されていない場合は、このAPIのラッパーを手動で作成する必要があります。

P/Invoke ラッパーの作成は難しく、エラーが発生しやすい場合があります。ネイティブ DLL を使用すると、プログラマーは .NET 環境で通常提供されるタイプの安全性とガベージ コレクションの恩恵を受けられなくなります。これらを不適切に使用すると、セグメンテーション エラーやメモリ リークなどの問題が発生する可能性があります。.NET環境で使用するレガシー関数の正確な署名を取得することは困難であり、このような問題が発生する可能性があります。この目的のために、署名を取得するためのツールや Web サイトが存在し、署名の問題を防ぐのに役立ちます。[1]

その他の落とし穴は次のとおりです。

• マネージ言語でのユーザー定義型のデータ配置が正しくありません。C のコンパイラまたはコンパイラ ディレクティブに応じて、データの配置方法が異なります。非 blittable 型のデータの配置方法をCLRに明示的に指示するように注意する必要があります。一般的な例としては、 Cの共用体を表すために .NET でデータ型を定義しようとする場合が挙げられます。2 つの異なる変数がメモリ内で重複しており、.NET の型でこれらの 2 つの変数を定義すると、メモリ内の異なる場所に配置されます。そのため、特別な属性を使用して問題を修正する必要があります。
• マネージ言語のガベージ コレクターによるデータの場所の干渉: 参照が .NET のメソッドに対してローカルであり、ネイティブ関数に渡される場合、マネージ メソッドが返されるときに、ガベージ コレクターがその参照を再利用することがあります。オブジェクト参照が固定され、ガベージ コレクターによって収集または移動されないように注意する必要があります。そうしないと、ネイティブ モジュールによる無効なアクセスが発生します。

C++/CLI を使用する場合、発行された CIL は、マネージド ヒープにあるオブジェクトと同時に、アドレス指定可能なネイティブ メモリの場所と自由に対話できます。マネージド ヒープ常駐オブジェクトは、単純な "object->field;" 表記を使用して値を割り当てたり、メソッド呼び出しを指定したりすることで、呼び出し、変更、または構築できます。不要なコンテキスト切り替えがなくなるため、パフォーマンスが大幅に向上し、メモリ要件が削減されます (スタックが短くなります)。

これには新たな課題が伴います:

• コードは、特に対処しないとダブルサンキング^[2]になりやすい
• ローダーロック問題 ^[3]

これらのリファレンスでは、それぞれの問題が発生した場合の解決策が示されています。主な利点は、構造体の宣言が不要になることです。フィールド宣言の順序とアライメントの問題は、C++ Interop のコンテキストでは発生しません。

この最初の簡単な例は、特定のDLLのバージョンを取得する方法を示しています。

Windows APIのDllGetVersion関数シグネチャ:

HRESULT DllGetVersion ( DLLVERSIONINFO * pdvi ) 

     

DllGetVersion関数を呼び出すには、 P/Invoke C#コードを使用します。

[StructLayout(LayoutKind.Sequential)]
プライベート構造体DLLVERSIONINFO { public int cbSize ; public int dwMajorVersion ; public int dwMinorVersion ; public int dwBuildNumber ; public int dwPlatformID ; } [DllImport("shell32.dll")] static extern int DllGetVersion ( ref DLLVERSIONINFO pdvi );   
      
      
      
      
      


     

2 番目の例は、ファイル内のアイコンを抽出する方法を示しています。

Windows API の ExtractIcon関数シグネチャ:

HICON ExtractIcon ( HINSTANCE hInst 、LPCTSTR lpszExeFileName 、UINT nIconIndex ); 
      
     
     
     

P/Invoke C# コードを使用して、ExtractIcon関数を呼び出します。

[DllImport("shell32.dll")] 
static extern IntPtr ExtractIcon ( IntPtr hInst 、[MarshalAs(UnmanagedType.LPStr)] string lpszExeFileName 、uint nIconIndex );   
      
       
     

次の複雑な例は、 Windows プラットフォームの 2 つのプロセス間でイベントを共有する方法を示しています。

CreateEvent関数のシグネチャ:

 HANDLE CreateEvent ( LPSECURITY_ATTRIBUTES lpEventAttributes 、BOOL bManualReset 、BOOL bInitialState 、LPCTSTR lpName ); 
      
      
      
      
 

CreateEvent関数を呼び出すには、P/Invoke C# コードを使用します。

[DllImport("kernel32.dll", SetLastError=true)] 
static extern IntPtr CreateEvent ( IntPtr lpEventAttributes 、bool bManualReset 、bool bInitialState 、[MarshalAs(UnmanagedType.LPStr)]文字列lpName );   
      
     
      
      

// ネイティブ宣言
typedef struct _PAIR { DWORD Val1 ; DWORD Val2 ; } PAIR , * PPAIR ;   
 
	  
	  
  

// /clr でコンパイルされています。#pragma managed/unmanaged を使用すると、二重サンクが発生する可能性があります。// 
.h インクルードを含むスタンドアロン .cpp を使用して回避します。//
これは .h ファイル内にあります。

template <> 
inline CLR_PAIR ^ marshal_as < CLR_PAIR ^ , PAIR > ( const PAIR & Src ) { // 逆参照の使用に注意してください。使用方法と一致している必要があります。CLR_PAIR ^ Dest = gcnew CLR_PAIR ; Dest -> Val1 = Src . Val1 ; Dest -> Val2 = Src . Val2 ; return Dest ; };          
	    
	  
	  
	 

CLR_PAIR ^ mgd_pair1 ; CLR_PAIR ^ mgd_pair2 ; PAIR native0 , * native1 =& native0 ; 
 
 

ネイティブ0 = NativeCallGetRefToMemory ();  

// marshal_as を使用します。大きな型や頻繁に使用される型の場合に適しています。
mgd_pair1 = marshal_as < CLR_PAIR ^> ( * native1 );  

// 直接フィールドの使用
mgd_pair2 -> Val1 = native0 . Val1 ; mgd_pair2 -> val2 = native0 . val2 ;  
  

return ( mgd_pair1 ); // C#に戻る 

P/Invoke 署名の作成を支援するために設計されたツールが多数あります。

C++ ヘッダー ファイルとネイティブDLLファイルをインポートし、インターフェイス アセンブリを自動的に生成するユーティリティ アプリケーションを作成するのは、非常に困難です。P/Invoke シグネチャ用のこのようなインポーター/エクスポーターを作成する際の主な問題は、一部の C++ 関数呼び出しパラメータの型があいまいなことです。

ブラッド・エイブラムスはこの件について次のように述べています: ^[4]

問題は次のような C++ 関数にあります。

__declspec ( dllexport ) void MyFunction ( char * params );   

P/Invoke シグネチャのパラメータparamsにはどの型を使用すればよいでしょうか。これは、C++ の null で終了する文字列、 char配列、または出力charパラメータのいずれかになります。string 、StringBuilder、char []、またはref char のどれを使用すればよいでしょうか 。

この問題に関係なく、P/Invoke 署名の作成を簡素化するツールがいくつかあります。

以下にリストされているツールの 1 つである xInterop C++ .NET Bridge は、.NET の世界で同じ C++ メソッドの複数のオーバーライドを実装することでこの問題を解決し、開発者は正しいオーバーライドを選択して呼び出しを行うことができます。

PInvoke.net は、多数の標準 Windows API の P/Invoke 署名を含む wiki です。Redgate Software が所有しており、毎月約 50,000 回のアクセスがあります。

署名は Wiki のユーザーによって手動で作成されます。Microsoft Visual Studioの無料アドインを使用して検索できます。

PInvoker は、ネイティブ DLL と C++ .h ファイルをインポートし、完全に形成されコンパイルされたP/Invoke相互運用 DLL をエクスポートするアプリケーションです。ネイティブ ポインター関数パラメータを PInvoker 固有の .NET インターフェイス クラスにラップすることで、あいまいさの問題を解決します。P/Invoke メソッド定義で標準の .NET パラメータ型 ( char[]、stringなど)を使用する代わりに、P/Invoke 関数呼び出しでこれらのインターフェイス クラスを使用します。

たとえば、上記のサンプル コードを検討すると、PInvoker はネイティブchar *ポインターをラップする .NET インターフェイス クラスを受け入れる.NET P/Invoke関数を生成します。このクラスは、文字列またはchar []配列から構築できます。実際のネイティブ メモリ構造はどちらも同じですが、各タイプのインターフェイス クラス コンストラクターは、異なる方法でメモリを設定します。したがって、関数に渡す必要がある .NET タイプを決定する責任は開発者に委ねられます。

Microsoft Interop Assistant は、 CodePlexからダウンロードできるバイナリとソース コードが付属した無料ツールです。Microsoft Limited Public License (Ms-LPL) に基づいてライセンスされます。

2つの部分から構成されています:

• 構造体とメソッドの定義を含むネイティブ C++ ヘッダー ファイル コードの小さなセクションを取得するコンバーター。次に、アプリケーションにコピーして貼り付けることができる C# P/Invoke コードを生成します。
• 変換された Windows API 定数、メソッド、および構造体の定義を検索できるデータベース。

このツールはコンパイルされた dll ではなく C# ソース コードを生成するため、ユーザーは使用前にコードに必要な変更を自由に行うことができます。したがって、あいまいさの問題は、アプリケーションが P/Invoke メソッド シグネチャで使用する特定の .NET 型を 1 つ選択することで解決され、必要に応じてユーザーはこれを必要な型に変更できます。

P/Invoke ウィザードは、ネイティブ C++ .h ファイル コードを受け入れ、.NET アプリケーション コードに貼り付けるための C# (または VB.NET) コードを生成するという点で、Microsoft Interop Assistant と同様の方法を使用します。

また、ターゲットとするフレームワークのオプションも用意されています。デスクトップの場合は .NET Framework、Windows Mobile スマート デバイス (および Windows CE) の場合は .NET Compact Framework です。

xInterop C++ .NET Bridge は、ネイティブ C++ DLL 用の C# ラッパーと、.NET アセンブリにアクセスするための C++ ブリッジを作成するための Windows アプリケーションです。文字列、iostream などの標準 C++ クラスをラップする C#/.NET ライブラリが付属しており、C++ クラスとオブジェクトに .NET からアクセスできます。

このツールは、既存のネイティブ C++ DLL からのソース コードと、ツールが C# ラッパー DLL を構築するために必要な関連ヘッダー ファイルを使用して、C# ラッパー DLL を生成します。P/Invoke 署名とデータ マーシャリングは、アプリケーションによって生成されます。結果として得られる C# ラッパーは、パラメーター タイプが .NET コードに変換された、C++ 対応のインターフェイスに似ています。

このツールは、C++ DLL からエクスポートされていないテンプレート クラスを認識し、テンプレート クラスをインスタンス化して補足 DLL にエクスポートし、対応する C++ インターフェイスを .NET で使用できるようにします。

• Blittable 型
• Java Native Interface、Java プログラムがネイティブ コードにアクセスするための標準的な方法
• Java Native Access は、P/Invoke の Java 版です。
• Windows ライブラリ ファイル
• J/Direct 、 Microsoft Java Virtual Machineの同等の API はメンテナンスされなくなりました。

• P/Invokeに特化したサイト