全般的な考慮事項
マネージ コードとアンマネージ コードの間で行われるすべての呼び出しは、各プログラミング モデルによって設定される要件をネゴシエートする必要があります。マネージ プログラミング モデルとアンマネージ プログラミング モデルは、多くの点で異なります。各モデルの特性を定義している表を次に示します。
| 特性 | アンマネージ モデル | マネージ モデル |
|---|---|---|
コーディング モデル |
インターフェイス ベースのモデル |
オブジェクト ベースのモデル |
厳密等価 |
GUID |
厳密な名前 |
エラー処理機構 |
HRESULT |
例外 |
型の互換性 |
バイナリ標準 |
型標準 |
型定義 |
タイプ ライブラリ |
メタデータ |
タイプ セーフ |
タイプ セーフでない |
(場合に応じて) セーフ |
バージョン管理 |
変更不可 |
変更可能 |
プログラミング モデルの中には、その特性がタイプ ライブラリやメタデータなど、表示できるエントリに関連付けられているモデルもあります。グローバル一意識別子 (GUID: Globally Unique Identifier) や厳密な名前など、引数として渡すことができる特性もあります。それ以外の特性はより概念的です。アプリケーション デザインに対するこのような特性の影響を考慮することは当然ですが、マネージ モデルとアンマネージ モデルの間で直接対応付けが行われることはありません。
各特性の詳細については、次のセクションで説明します。
コーディング モデル
アンマネージ オブジェクトは、常にインターフェイスを通じて通信しますが、マネージ オブジェクトおよびマネージ クラスは、インターフェイスを実装しなくても、データを直接渡すことができます。既定では、オブジェクトまたはクラスがインターフェイスを実装していない場合に、COM 相互運用がクラス インターフェイスを生成し、そのインターフェイスを通じてマネージ機能を COM に公開します。
- エラー処理機構
通常、COM メソッドは、HRESULT を返して、その呼び出しの成否を示します。マネージ コードは例外を組み込みます。既定では、COM 相互運用はマネージ例外をエラー HRESULT に割り当てます。
- ID
GUID は、特定のアンマネージ型を識別しますが、その型の位置情報は提供しません。厳密な名前は、型名のほかに、一意のアセンブリ名からも構成されます。アセンブリ名は型を個別に識別するため、複数のアセンブリにまたがって型名を再利用できます。アセンブリは、マネージ型に対して発行元キー、バージョン、および位置情報も取り入れます。相互運用サービスは、GUID を生成し、必要な場合には厳密な名前付きにします。
- 型の互換性
型は、マネージ コードとアンマネージ コードとでは異なり、各言語間でも異なります。
- 型定義
タイプ ライブラリの使用に慣れていれば、タイプ ライブラリに含まれる型がパブリック型だけなのは既にご存知でしょう。その上タイプ ライブラリは省略できます。マネージ プログラミング モデルの場合、すべての型に対して型情報が必須です。相互運用サービスでは、タイプ ライブラリをアセンブリ内のメタデータを変換したり、メタデータをタイプ ライブラリに変換したりするためのツールを提供しています。
- タイプ セーフ
アンマネージ コンパイラでは、ポインタ型に関して型チェックを行っていないため、害を及ぼす可能性のあるアクティビティの影響を受けやすくなっています。通常、マネージ コードには、より高い信頼のレベルが要求されます。プログラマはマネージ コードでポインタを使用し続けることができますが、その安全でない動作によってコードが制約を受けます。相互運用サービスは、信頼できないマネージ コードがアンマネージ コードにアクセスしないようにします。
- バージョン管理
COM インターフェイスは、変更不可です。インターフェイスを変更する場合は、新しい GUID でその名前を変更する必要があります。マネージ型は、同じ名前を維持したままで展開できます。