相互運用のためのデザインの考慮事項

  • [アーティクル]

この概要では、マネージ プログラミング モデルとアンマネージ プログラミング モデルの違いを説明します。 推奨事項とデザイン時の相互運用方法については、「相互運用性を得るための COM コンポーネントの作成」および「相互運用のための .NET Framework コンポーネントの作成」を参照してください。

マネージ コードとアンマネージ コードの間で行われるすべての呼び出しは、各プログラミング モデルによって設定される要件をネゴシエートする必要があります。 マネージ プログラミング モデルとアンマネージ プログラミング モデルは、多くの点で異なります。 各モデルの特性を定義している表を次に示します。

特性

アンマネージ モデル

マネージ モデル

[詳細]

コーディング モデル

インターフェイス ベースのモデル

オブジェクト ベースのモデル

アンマネージ オブジェクトは、常にインターフェイスを通じて通信しますが、マネージ オブジェクトおよびマネージ クラスは、インターフェイスを実装しなくても、データを直接渡すことができます。

既定では、オブジェクトまたはクラスがインターフェイスを実装していない場合に、COM 相互運用がクラス インターフェイスを生成し、そのインターフェイスを通じてマネージ機能を COM に公開します。

[ID]

GUID

厳密な名前

GUID は、特定のアンマネージ型を識別しますが、その型の位置情報は提供しません。 厳密な名前は、型名のほかに、一意のアセンブリ名からも構成されます。 アセンブリ名は型を個別に識別するため、複数のアセンブリにまたがって型名を再利用できます。 アセンブリは、マネージ型に対して発行元キー、バージョン、および位置情報も取り入れます。 相互運用サービスは、GUID を生成し、必要な場合には厳密な名前付きにします。

エラー処理機構

HRESULT

例外

通常、COM メソッドは、HRESULT を返して、その呼び出しの成否を示します。 マネージ コードは例外を組み込みます。 既定では、COM 相互運用はマネージ例外をエラー HRESULT に割り当てます。

PODS (Plain Old Data Structure)

構造体

オブジェクトから派生するマネージ構造体

構造体またはクラスにコンストラクターが含まれている場合、プラットフォーム呼び出しを使用して、これらを値渡しで返すことはできません。 一般に、非 PODS 要素が含まれるユーザー定義型は参照渡しで返されます。 PODS とは、ISO/IEC 規格 14882「Programming Languages — C++」で定義されているとおり、フィールド値の受動的な集まりのみが含まれるデータ構造です。 コンストラクター、コピー代入演算子、デストラクターや、それ自体 PODS でない非静的データ メンバーは含まれません。

型の互換性

バイナリ標準

型標準

型は、マネージ コードとアンマネージ コードとでは異なり、各言語間でも異なります。

型定義

タイプ ライブラリ

メタデータ

タイプ ライブラリの使用に慣れていれば、タイプ ライブラリに含まれる型がパブリック型だけなのは既にご存知でしょう。 その上タイプ ライブラリは省略できます。 マネージ プログラミング モデルの場合、すべての型に対して型情報が必須です。 相互運用サービスでは、タイプ ライブラリをアセンブリ内のメタデータを変換したり、メタデータをタイプ ライブラリに変換したりするためのツールを提供しています。

タイプ セーフ

タイプ セーフでない

(場合に応じて) セーフ

アンマネージ コンパイラでは、ポインター型に関して型チェックを行っていないため、害を及ぼす可能性のあるアクティビティの影響を受けやすくなっています。 通常、マネージ コードには、より高い信頼のレベルが要求されます。 プログラマはマネージ コードでポインターを使用し続けることができますが、その安全でない動作によってコードが制約を受けます。 相互運用サービスは、信頼できないマネージ コードがアンマネージ コードにアクセスしないようにします。

バージョン管理

変更不可

変更可能

COM インターフェイスは、変更不可です。 インターフェイスを変更する場合は、新しい GUID でその名前を変更する必要があります。 マネージ型は、同じ名前を維持したままで展開できます。

プログラミング モデルの中には、その特性がタイプ ライブラリやメタデータなど、表示できるエントリに関連付けられているモデルもあります。 GUID や厳密な名前など、引数として渡すことができる特性もあります。 それ以外の特性はより概念的です。アプリケーション デザインに対するこのような特性の影響を考慮することは当然ですが、これらの特性は、マネージ モデルとアンマネージ モデルの間で直接は対応していません。

関連トピック

タイトル

説明

相互運用性を得るための COM コンポーネントの作成

COM コンポーネントのデザイン時の相互運用方法について説明します。

相互運用のための .NET Framework コンポーネントの作成

.NET Framework コンポーネントのデザイン時の相互運用方法について説明します。

アンマネージ コードとの相互運用

COM 相互運用機能とプラットフォーム呼び出しの使用方法について説明します。

高度な COM 相互運用性

COM 相互運用機能の概念と変換規則について説明します。

相互運用マーシャリング

相互運用マーシャリング サービス、その COM マーシャリングとの関係、およびリモート通信におけるその役割について説明します。