既定のマーシャリング動作

相互運用マーシャリングは、メソッド パラメーターに関連付けられているデータがマネージド メモリとアンマネージド メモリの間を通過する場合の動作を決定するルールに対して動作します。 これらの組み込みルールは、データ型変換などのマーシャリング アクティビティ、呼び出し先が渡されたデータを変更して呼び出し元にそれらの変更を返すことができるかどうか、およびマーシャラーがパフォーマンスの最適化を提供する状況を制御します。

このセクションでは、相互運用マーシャリング サービスの既定の動作特性を識別します。 配列、ブール型、char 型、デリゲート、クラス、オブジェクト、文字列、構造体のマーシャリングに関する詳細情報が表示されます。

インターオペレーション マーシャラーを使用したメモリ管理

相互運用マーシャラーは常に、アンマネージ コードによって割り当てられたメモリの解放を試みます。 この動作は COM メモリ管理規則に準拠していますが、ネイティブ C++ を管理する規則とは異なります。

プラットフォーム呼び出しを使用するときにネイティブの C++ 動作 (メモリ解放なし) が予想される場合、混乱が発生する可能性があります。プラットフォーム呼び出しでは、ポインターのメモリが自動的に解放されます。 たとえば、C++ DLL から次のアンマネージ メソッドを呼び出しても、メモリは自動的に解放されません。

非管理署名

BSTR MethodOne (BSTR b) {
     return b;
}

ただし、プラットフォーム呼び出しプロトタイプとしてメソッドを定義し、各 BSTR 型を String 型に置き換え、 MethodOneを呼び出すと、共通言語ランタイムは b を 2 回解放しようとします。 マーシャリング動作は、IntPtr型ではなくString型を使用して変更できます。

ランタイムでは、常に Windows の CoTaskMemFree メソッドと、他のプラットフォームの free メソッドを使用してメモリを解放します。 使用しているメモリが Windows の CoTaskMemAlloc メソッドまたは他のプラットフォームの malloc メソッドで割り当てられなかった場合は、 IntPtr を使用し、適切なメソッドを使用してメモリを手動で解放する必要があります。 同様に、カーネル メモリへのポインターを返す Kernel32.dllから GetCommandLine 関数を使用する場合など、メモリを解放しない状況で、メモリの自動解放を回避できます。 メモリを手動で解放する方法の詳細については、 バッファーのサンプルを参照してください。

クラスに対する既定のマーシャリング

クラスは COM 相互運用によってのみマーシャリングでき、常にインターフェイスとしてマーシャリングされます。 場合によっては、クラスのマーシャリングに使用されるインターフェイスは、クラス インターフェイスと呼ばれます。 クラス インターフェイスを好みのインターフェイスでオーバーライドする方法については、「 クラス インターフェイスの概要」を参照してください。

COM にクラスを渡す

マネージド クラスが COM に渡されると、相互運用マーシャラーは自動的に COM プロキシでクラスをラップし、プロキシによって生成されたクラス インターフェイスを COM メソッド呼び出しに渡します。 プロキシは、クラス インターフェイスのすべての呼び出しをマネージド オブジェクトに委任します。 プロキシは、クラスによって明示的に実装されていない他のインターフェイスも公開します。 プロキシは、クラスに代わって、 IUnknown や IDispatch などのインターフェイスを自動的に実装します。

.NET コードにクラスを渡す

コクラスは、通常、COM のメソッド引数として使用されません。 代わりに、通常、既定のインターフェイスがコクラスの代わりに渡されます。

インターフェイスがマネージド コードに渡されると、相互運用マーシャラーはインターフェイスを適切なラッパーでラップし、ラッパーをマネージド メソッドに渡す役割を担います。 どのラッパーを使用するかは難しい判断となることがあります。 COM オブジェクトのすべてのインスタンスには、オブジェクトが実装するインターフェイスの数に関係なく、1 つの一意のラッパーがあります。 たとえば、5 つの異なるインターフェイスを実装する 1 つの COM オブジェクトには、ラッパーが 1 つだけ存在します。 同じラッパーは、5 つのインターフェイスすべてを公開します。 COM オブジェクトの 2 つのインスタンスが作成されると、ラッパーの 2 つのインスタンスが作成されます。

ラッパーが有効期間を通じて同じ型を維持するには、相互運用マーシャラーは、オブジェクトによって公開されたインターフェイスがマーシャラーを初めて通過する際に、正しいラッパーを識別する必要があります。 マーシャラーは、オブジェクトが実装するインターフェイスのいずれかを調べることで、オブジェクトを識別します。

たとえば、マーシャラーは、マネージド コードに渡されたインターフェイスをラップするためにクラス ラッパーを使用する必要があると判断します。 インターフェイスがマーシャラーを初めて通過すると、マーシャラーはインターフェイスが既知のオブジェクトから送信されているかどうかを確認します。 このチェックは、次の 2 つの状況で発生します。

• インターフェイスは、他の場所の COM に渡された別のマネージド オブジェクトによって実装されています。 マーシャラーは、マネージド オブジェクトによって公開されているインターフェイスを簡単に識別でき、実装を提供するマネージド オブジェクトとインターフェイスを照合できます。 その後、マネージド オブジェクトがメソッドに渡され、ラッパーは必要ありません。

• 既にラップされているオブジェクトは、インターフェイスを実装しています。 これが当てはまるかどうかを判断するために、マーシャラーはオブジェクトに IUnknown インターフェイスを照会し、返されたインターフェイスを、既にラップされている他のオブジェクトのインターフェイスと比較します。 インターフェイスが別のラッパーと同じ場合、オブジェクトは同じ ID を持ち、既存のラッパーがメソッドに渡されます。

インターフェイスが既知のオブジェクトからでない場合、マーシャラーは次の処理を行います。

1. マーシャラーは、 IProvideClassInfo2 インターフェイスのオブジェクトを照会します。 指定された場合、マーシャラーは IProvideClassInfo2.GetGUID から返された CLSID を使用して、インターフェイスを提供するコクラスを識別します。 CLSID を使用すると、アセンブリが以前に登録されている場合、マーシャラーはレジストリからラッパーを見つけることができます。

2. マーシャラーは、 IProvideClassInfo インターフェイスのインターフェイスに対してクエリを実行します。 指定した場合、マーシャラーは ITypeInfo から返されたを使用して、インターフェイスを公開するクラスの CLSID を決定します。 マーシャラーは CLSID を使用してラッパーのメタデータを見つけることができます。

3. マーシャラーがまだクラスを識別できない場合は、 インターフェイスを System.__ComObject という汎用ラッパー クラスでラップします。

デリゲートに対する既定のマーシャリング

マネージド デリゲートは、呼び出し元のメカニズムに基づいて、COM インターフェイスまたは関数ポインターとしてマーシャリングされます。

• プラットフォーム呼び出しの場合、デリゲートは既定でアンマネージ関数ポインターとしてマーシャリングされます。

• COM 相互運用機能の場合、デリゲートは既定で _Delegate 型の COM インターフェイスとしてマーシャリングされます。 _Delegate インターフェイスは Mscorlib.tlb タイプ ライブラリで定義され、デリゲートが参照するメソッドを呼び出すDelegate.DynamicInvoke メソッドが含まれています。

次の表に、マネージド デリゲート データ型のマーシャリング オプションを示します。 MarshalAsAttribute属性は、デリゲートをマーシャリングするためのいくつかのUnmanagedType列挙値を提供します。

DelegateTestInterfaceのメソッドを COM タイプ ライブラリにエクスポートするコード例を次に示します。 ref (または ByRef) キーワードでマークされたデリゲートのみが In/Out パラメーターとして渡されることに注意してください。

using System;
using System.Runtime.InteropServices;

public interface DelegateTest {
void m1(Delegate d);
void m2([MarshalAs(UnmanagedType.Interface)] Delegate d);
void m3([MarshalAs(UnmanagedType.Interface)] ref Delegate d);
void m4([MarshalAs(UnmanagedType.FunctionPtr)] Delegate d);
void m5([MarshalAs(UnmanagedType.FunctionPtr)] ref Delegate d);
}

タイプ ライブラリの表現

importlib("mscorlib.tlb");
interface DelegateTest : IDispatch {
[id(…)] HRESULT m1([in] _Delegate* d);
[id(…)] HRESULT m2([in] _Delegate* d);
[id(…)] HRESULT m3([in, out] _Delegate** d);
[id()] HRESULT m4([in] int d);
[id()] HRESULT m5([in, out] int *d);
   };

他のアンマネージ関数ポインターを逆参照できるのと同様に、関数ポインターは逆参照できます。

この例では、2 つのデリゲートが UnmanagedType.FunctionPtrとしてマーシャリングされると、結果は int と intへのポインターになります。 デリゲート型はマーシャリングされているため、ここで int は、メモリ内のデリゲートのアドレスである void (void*) へのポインターを表します。 つまり、この結果は 32 ビットの Windows システムに固有です。ここで int は関数ポインターのサイズを表しているためです。

たとえば、cb メソッドに渡されるSetChangeHandler オブジェクトへの参照が、cb メソッドの有効期間を超えてTest維持されないため、次のコードは正しくありません。 cb オブジェクトがガベージ コレクションされると、SetChangeHandlerに渡される関数ポインターは無効になります。

public class ExternalAPI {
   [DllImport("External.dll")]
   public static extern void SetChangeHandler(
      [MarshalAs(UnmanagedType.FunctionPtr)]ChangeDelegate d);
}
public delegate bool ChangeDelegate([MarshalAs(UnmanagedType.LPWStr) string S);
public class CallBackClass {
   public bool OnChange(string S){ return true;}
}
internal class DelegateTest {
   public static void Test() {
      CallBackClass cb = new CallBackClass();
      // Caution: The following reference on the cb object does not keep the
      // object from being garbage collected after the Main method
      // executes.
      ExternalAPI.SetChangeHandler(new ChangeDelegate(cb.OnChange));
   }
}

予期しないガベージ コレクションを補正するために、呼び出し元は、アンマネージ関数ポインターの使用中は cb オブジェクトが有効のまま保持されるようにする必要があります。 必要に応じて、次の例に示すように、関数ポインターが不要になったときにアンマネージ コードにマネージド コードに通知させることができます。

internal class DelegateTest {
   CallBackClass cb;
   // Called before ever using the callback function.
   public static void SetChangeHandler() {
      cb = new CallBackClass();
      ExternalAPI.SetChangeHandler(new ChangeDelegate(cb.OnChange));
   }
   // Called after using the callback function for the last time.
   public static void RemoveChangeHandler() {
      // The cb object can be collected now. The unmanaged code is
      // finished with the callback function.
      cb = null;
   }
}

値型に対する既定のマーシャリング

整数や浮動小数点数などのほとんどの値型は blittable であり、マーシャリングは必要ありません。 その他の non-blittable 型は、マネージドおよびアンマネージド メモリに類似しない表現があり、マーシャリングが必要です。 それでも他の型では、相互運用境界を越えて明示的な書式設定が必要です。

このセクションでは、次の書式設定された値型について説明します。

• プラットフォーム呼び出しで使用される値型

• COM 相互運用機能で使用される値型

このトピックでは、書式設定された型の説明に加えて、通常とは異なるマーシャリング動作を持つ システム値型 を識別します。

書式設定された型は、メモリ内のメンバーのレイアウトを明示的に制御する情報を含む複合型です。 メンバー レイアウト情報は、 StructLayoutAttribute 属性を使用して提供されます。 レイアウトには、次の LayoutKind 列挙値のいずれかを指定できます。

• LayoutKind.Auto

  共通言語ランタイムが、効率を高めるために型のメンバーを自由に並べ替え可能であることを示します。 ただし、アンマネージド コードに値型が渡されると、メンバーのレイアウトは予測可能になります。 このような構造体をマーシャリングしようとすると、自動的に例外が発生します。

• LayoutKind.Sequential

  型のメンバーが、マネージド型定義に表示される順序と同じ順序でアンマネージ メモリに配置されることを示します。

• LayoutKind.Explicit

  各フィールドに指定された FieldOffsetAttribute に従ってメンバーがレイアウトされることを示します。

プラットフォーム呼び出しで使用される値型

次の例では、 Point 型と Rect 型は 、StructLayoutAttribute を使用してメンバー レイアウト情報を提供します。

Imports System.Runtime.InteropServices
<StructLayout(LayoutKind.Sequential)> Public Structure Point
   Public x As Integer
   Public y As Integer
End Structure
<StructLayout(LayoutKind.Explicit)> Public Structure Rect
   <FieldOffset(0)> Public left As Integer
   <FieldOffset(4)> Public top As Integer
   <FieldOffset(8)> Public right As Integer
   <FieldOffset(12)> Public bottom As Integer
End Structure

using System.Runtime.InteropServices;
[StructLayout(LayoutKind.Sequential)]
public struct Point {
   public int x;
   public int y;
}

[StructLayout(LayoutKind.Explicit)]
public struct Rect {
   [FieldOffset(0)] public int left;
   [FieldOffset(4)] public int top;
   [FieldOffset(8)] public int right;
   [FieldOffset(12)] public int bottom;
}

アンマネージ コードにマーシャリングすると、これらの書式設定された型は C スタイルの構造体としてマーシャリングされます。 これにより、構造体引数を持つアンマネージ API を簡単に呼び出す方法が提供されます。 たとえば、 POINT および RECT 構造体は、次のように Microsoft Windows API PtInRect 関数に渡すことができます。

BOOL PtInRect(const RECT *lprc, POINT pt);

次のプラットフォーム呼び出し定義を使用して構造体を渡すことができます。

Friend Class NativeMethods
    Friend Declare Auto Function PtInRect Lib "User32.dll" (
        ByRef r As Rect, p As Point) As Boolean
End Class

internal static class NativeMethods
{
   [DllImport("User32.dll")]
   internal static extern bool PtInRect(ref Rect r, Point p);
}

アンマネージ API はRectへのポインターを関数に渡すことが想定されているため、RECT値型を参照渡しする必要があります。 Point値型は、アンマネージ API がスタックでPOINTが渡されることを想定しているため、値渡しされます。 この微妙な違いは非常に重要です。 参照は、ポインターとしてアンマネージ コードに渡されます。 値は、スタック上のアンマネージ コードに渡されます。

クラスは、固定メンバー レイアウトがある場合、C スタイルの構造体としてアンマネージ コードにマーシャリングすることもできます。 クラスのメンバー レイアウト情報も、 StructLayoutAttribute 属性と共に提供されます。 固定レイアウトの値型と固定レイアウトのクラスの主な違いは、アンマネージド コードにマーシャリングする方法です。 値型は (スタック上の) 値によって渡されるため、呼び出し先によって型のメンバーに加えられた変更は呼び出し元には表示されません。 参照型は参照によって渡されます (型への参照はスタックで渡されます)。したがって、呼び出し先によって型の blittable 型メンバーに加えられたすべての変更が呼び出し元によって表示されます。

次の例では、 SystemTime クラスはシーケンシャル メンバー レイアウトを持ち、Windows API GetSystemTime 関数に渡すことができます。

<StructLayout(LayoutKind.Sequential)> Public Class SystemTime
   Public wYear As System.UInt16
   Public wMonth As System.UInt16
   Public wDayOfWeek As System.UInt16
   Public wDay As System.UInt16
   Public wHour As System.UInt16
   Public wMinute As System.UInt16
   Public wSecond As System.UInt16
   Public wMilliseconds As System.UInt16
End Class

[StructLayout(LayoutKind.Sequential)]
   public class SystemTime {
   public ushort wYear;
   public ushort wMonth;
   public ushort wDayOfWeek;
   public ushort wDay;
   public ushort wHour;
   public ushort wMinute;
   public ushort wSecond;
   public ushort wMilliseconds;
}

GetSystemTime関数は次のように定義されます。

void GetSystemTime(SYSTEMTIME* SystemTime);

GetSystemTimeの同等のプラットフォーム呼び出し定義は次のとおりです。

Friend Class NativeMethods
    Friend Declare Auto Sub GetSystemTime Lib "Kernel32.dll" (
        ByVal sysTime As SystemTime)
End Class

internal static class NativeMethods
{
   [DllImport("Kernel32.dll", CharSet = CharSet.Auto)]
   internal static extern void GetSystemTime(SystemTime st);
}

SystemTimeは値型ではなくクラスであるため、SystemTime引数は参照引数として型指定されていないことに注意してください。 値型とは異なり、クラスは常に参照によって渡されます。

次のコード例は、Point というメソッドを持つ別のSetXY クラスを示しています。 型にはシーケンシャル レイアウトがあるため、アンマネージ コードに渡して構造体としてマーシャリングできます。 ただし、オブジェクトが参照渡しであっても、 SetXY メンバーはアンマネージ コードから呼び出すことができません。

<StructLayout(LayoutKind.Sequential)> Public Class Point
   Private x, y As Integer
   Public Sub SetXY(x As Integer, y As Integer)
      Me.x = x
      Me.y = y
   End Sub
End Class

[StructLayout(LayoutKind.Sequential)]
public class Point {
   int x, y;
   public void SetXY(int x, int y){
      this.x = x;
      this.y = y;
   }
}

COM 相互運用機能で使用される値型

書式設定された型は、COM 相互運用メソッド呼び出しにも渡すことができます。 実際、タイプ ライブラリにエクスポートすると、値型は自動的に構造体に変換されます。 次の例に示すように、 Point 値型は、 Pointという名前の型定義 (typedef) になります。 タイプ ライブラリ内の別の場所にある Point 値型への参照はすべて、 Point typedef に置き換えられます。

型ライブラリの表現

typedef struct tagPoint {
   int x;
   int y;
} Point;
interface _Graphics {
   …
   HRESULT SetPoint ([in] Point p)
   HRESULT SetPointRef ([in,out] Point *p)
   HRESULT GetPoint ([out,retval] Point *p)
}

COM インターフェイスを介してマーシャリングするときに、値とプラットフォーム呼び出しへの参照をマーシャリングするために使用されるのと同じ規則が使用されます。 たとえば、Point値型のインスタンスが .NET ランタイムから COM に渡されると、Pointは値渡しされます。 Point値型が参照渡しの場合、Pointへのポインターがスタックに渡されます。 相互運用マーシャラーでは、どちらの方向についても、より高いレベルの間接参照 (Point **) はサポートされていません。

システムの値型

System名前空間には、ランタイム プリミティブ型のボックス化された形式を表す複数の値型があります。 たとえば、値型 System.Int32 構造体は、ボックス化された 形式のELEMENT_TYPE_I4を表します。 他の書式設定された型と同様に、これらの型を構造体としてマーシャリングする代わりに、ボックス化されたプリミティブ型と同じ方法でマーシャリングします。 したがって、System.Int32 は long 型の 1 つのメンバーを含む構造体としてではなく、ELEMENT_TYPE_I4としてマーシャリングされます。 次の表に、プリミティブ型のボックス化表現である System 名前空間の値型の一覧を示します。

System名前空間のその他の値型の処理方法は異なります。 アンマネージド コードではこれらの型の形式が既に確立されているため、マーシャラーには、それらをマーシャリングするための特別な規則があります。 次の表は、System 名前空間の特殊な値型と、それに対してマーシャリングされるアンマネージ型を一覧します。

次のコードは、Stdole2 タイプ ライブラリのアンマネージ型 DATE、 GUID、 DECIMAL、および OLE_COLOR の定義を示しています。

タイプ ライブラリの表現

typedef double DATE;
typedef DWORD OLE_COLOR;

typedef struct tagDEC {
    USHORT    wReserved;
    BYTE      scale;
    BYTE      sign;
    ULONG     Hi32;
    ULONGLONG Lo64;
} DECIMAL;

typedef struct tagGUID {
    DWORD Data1;
    WORD  Data2;
    WORD  Data3;
    BYTE  Data4[ 8 ];
} GUID;

次のコードは、マネージド IValueTypes インターフェイスの対応する定義を示しています。

Public Interface IValueTypes
   Sub M1(d As System.DateTime)
   Sub M2(d As System.Guid)
   Sub M3(d As System.Decimal)
   Sub M4(d As System.Drawing.Color)
End Interface

public interface IValueTypes {
   void M1(System.DateTime d);
   void M2(System.Guid d);
   void M3(System.Decimal d);
   void M4(System.Drawing.Color d);
}

タイプ ライブラリの表現

[…]
interface IValueTypes : IDispatch {
   HRESULT M1([in] DATE d);
   HRESULT M2([in] GUID d);
   HRESULT M3([in] DECIMAL d);
   HRESULT M4([in] OLE_COLOR d);
};

こちらも参照ください

• Blittable 型と非 Blittable 型
• コピーとピン留め
• 配列の既定のマーシャリング
• オブジェクトの既定のマーシャリング
• 文字列の既定のマーシャリング