次の方法で共有

プライマリ相互運用機能アセンブリ (PIA)

  • [アーティクル]

 

Microsoft Corporation

2002 年 1 月

概要： このドキュメントでは、共通言語ランタイムと相互運用する既存の COM 型のセットについて説明するメタデータを作成するプロセスについて説明します。 (7ページ印刷)

内容

メタデータと共通言語ランタイム
PIA に関する一般的な質問
   PIA とは
   PIA が重要なのはなぜですか?
   COM タイプ ライブラリの PIA を作成操作方法
   PIA を使用しない場合はどうすればよいですか?
   PIA をカスタマイズするにはどうすればよいですか?
   共通言語ランタイムと Visual Studio では、PIA の処理方法はどのように異なりますか?
   複数の PIA を 1 つのファイルに結合できますか?
   PIA にはどのような名前空間を使用する必要がありますか?
   PIA にはどのようなファイル名を使用する必要がありますか?
   PIA に署名するためのキーはどこで入手できますか?
   PIA を開発者に配布操作方法。
   PIA を発送後に変更または修正することはできますか?
   PIA の発行元ポリシーを作成できますか?
   PIA を使用しない場合は問題ありませんか?
   Microsoft および Microsoft 以外の製品の PIA はどこで入手できますか?

メタデータと共通言語ランタイム

既存の COM 型と相互運用するには、共通言語ランタイムで理解できる形式でこれらの型の説明が必要です。 共通言語ランタイムによって認識される型情報の形式は メタデータと呼ばれ、 マネージド アセンブリ内に含まれています。 そのため、アプリケーションを COM 型と相互運用するには、使用されている型のメタデータ記述が必要です。

このドキュメントでは、既存の COM 型のセットを記述するメタデータを作成するプロセスについて説明します。 メタデータは、基本的に COM タイプ ライブラリと同等の実行時です。 既存の COM 型を使用するにはメタデータが必要であるため、COM タイプ ライブラリを発行した開発者は、COM ライブラリのメタデータを作成する方法に特に関心を持つ必要があります。

PIA に関する一般的な質問

PIA とは

他のマネージド アセンブリと同様に、相互運用機能アセンブリは、1 つのユニットとして展開、バージョン管理、および構成される型のコレクションです。 ただし、他のマネージド アセンブリとは異なり、相互運用機能アセンブリには、COM で既に定義されている型の型定義 (実装ではない) が含まれています。 これらの型定義を使用すると、マネージド アプリケーションはコンパイル時に COM 型にバインドし、実行時に型をマーシャリングする方法に関する情報を共通言語ランタイムに提供できます。

特定の COM 型を記述する任意の数の相互運用機能アセンブリが存在する場合でも、PIA にラベルが付けられる相互運用機能アセンブリは 1 つだけです。 PIA には、これらの型の発行元によって定義されている型の公式な説明が含まれています。 PIA には、マネージド コードから型を使いやすくする特定のカスタマイズが含まれている場合があります。 PIA は、常に元の COM 型の発行元によって署名されます。

COM 型の発行元によって提供されない相互運用機能アセンブリは非公式と見なされるため、回避する必要があります。 このようなアセンブリで定義されている型は PIA の発行元によって署名されないため、PIA で提供される定義と互換性がありません。

PIA が重要なのはなぜですか?

PIA は一意の型 ID を提供するため、重要です。 PIA は、公式の型定義を、他の相互運用機能アセンブリによって提供される偽造定義と区別します。 単一の型 ID を使用すると、PIA で定義されている型を共有するアプリケーション間で型の互換性が確保されます。 PIA はパブリッシャーによって署名され、 PrimaryInteropAssembly 属性でラベル付けされているため、同じ型を定義する他の相互運用機能アセンブリと区別できます。

COM タイプ ライブラリの PIA を作成操作方法

ほとんどの場合、PIA の作成は簡単です。 Microsoft® .NET Framework SDK で提供されている Tlbimp (タイプ ライブラリ インポーター) ツールは、既存のタイプ ライブラリから相互運用機能アセンブリを作成できます。 Tlbimp の /primary スイッチを使用して PIA を作成します。 パブリッシャー キーを /keyfile スイッチと共に指定する必要があるため、すべての PIA に発行元が署名する必要があります。 次に例を示します。

TlbImp Widget.tlb /primary /keyfile:AcmeKey.snk /out:WidgetLib.dll

上の例では、Widget.tlb はインポートされるタイプ ライブラリです。AcmeKey.snk は Acme Company の公開キーを含むキーファイルであり、WidgetLib.dllは生成される PIA です。 テスト キーファイルは、SN ユーティリティ (SN.EXE —k AcmeKey.snk) を使用して生成できます。 アセンブリを実際に展開する前に、会社の実際のキーで署名する必要があります。 同じキーを使用して、1 つの会社のすべてのアセンブリに署名する必要があります。

PIA は、他の PIA のみを参照できます。 したがって、親アセンブリの PIA を生成する前に、依存アセンブリの PIA を生成する必要があります。 アセンブリの PIA を作成するために、別の会社から PIA を取得する必要がある場合があります。 すべての依存アセンブリを作成したら、Tlbimp の /reference スイッチを使用して参照を追加できます。

TlbImp WidgetUtil.tlb /primary /keyfile:AcmeKey.snk /out:WidgetUtil.dll
TlbImp Widget.tlb /primary /keyfile:AcmeKey.snk 
            /reference:WidgetUtil.dll /out:WidgetLib.dll

ほとんどの場合、相互運用機能アセンブリは Tlbimp ツールによって生成されます。 相互運用機能アセンブリは、マネージド ソース コード (C#など) から直接生成される場合があります。 ソース コードから生成された相互運用機能アセンブリは、 PrimaryInteropAssembly 属性 と Guid 属性 をアセンブリに追加することで、PIA にすることができます。 次に例を示します。

// assign the assembly the Guid o the type library 
[assembly:Guid("97d25db0-0363-1cf-abc4-02608 c9e7553"] 

// indicate that this assembly is the PIA for version 4.2 of the tlb
[assembly:PrimaryInteropAssembly(4, 2)]

PIA を使用しない場合はどうすればよいですか?

PIA を使用しないと、顧客の型の非互換性が発生します。 たとえば、A 社は、マネージド アプリケーション内で Acme Company によって提供される COM Widget オブジェクトを使用します。 A 社は、Acme 社が提供する PIA を使用するのではなく、Acme のウィジェット ライブラリの定義を含む別の相互運用アセンブリを作成することにしました。

B 社は、ウィジェット ライブラリの PIA を Acme Company から直接取得し、マネージド アプリケーション内で使用します。 どちらのアプリケーションも、A 社と B 社の一般的な顧客の開発者が、A 社から B 社にウィジェットを渡そうとするたびに型の不一致が発生し続ける理由を確認するよう呼び出すまで、単独で正常に動作します。

型が一致しない理由は、会社 A で使用されるウィジェットの種類が、会社 B で使用されるウィジェットの種類とは完全に異なるためです。どちらも同じ名前ですが、各相互運用機能アセンブリは異なる発行元によって署名されているため、型に互換性がありません。 このシンプルなソリューションは、両方の企業が Acme Company によって提供される PIA を使用することです。

PIA をカスタマイズするにはどうすればよいですか?

発行元が PIA をカスタマイズする必要がある場合があります。 たとえば、発行元は次の手順を実行できます。

  • アセンブリ内の特定の要素の名前を変更または非表示にします。
  • 属性を追加してマーシャリング動作を変更します。

バージョン 1.0 リリースでは、カスタム PIA を作成する方法が 2 つあります。

  1. マネージ言語とさまざまなカスタム属性を使用して、PIA の型定義をソース コードで作成します。
  2. Tlbimp を使用して PIA を生成します。PIA は、Tlbimp によって生成される Microsoft 中間言語 (MSIL) 型定義を変更することによってカスタマイズされます。

このような変更を行う唯一のツールは、ILDASM と ILASM です。 処理の手順は次のとおりです。

  1. 通常どおり、Tlbimp を使用してタイプ ライブラリをインポートします。

    TlbImp MyLib.tlb /primary /out:MyLib.dll

  2. ILDasm を使用して、アセンブリの MSIL ソース コードを生成します。

    ILDASM MyLib.dll /out=MyLib.il

  3. 必要に応じて、お気に入りのテキスト エディターで MSIL コードを変更します。

    Notepad MyLib.il

  4. ILASM コンパイラを使用して MSIL を再コンパイルします。

    ILAsm /DLL /KEY=MyKey.snk MyLib.il

上記の手順 2 では、リソースがアセンブリで見つかった場合に RES ファイルが生成される場合もあります。 RES ファイルが生成された場合は、ILASM の /resource オプションを使用して、手順 4 でアセンブリにコンパイルし直す必要があります。

共通言語ランタイムと Visual Studio では、PIA の処理方法はどのように異なりますか?

PIA ができるだけ頻繁に使用されるようにするために、共通言語ランタイムと Microsoft® Visual Studio® は PIA を他のアセンブリとは少し異なる方法で処理します。

登録時: PIA は RegAsm ツールに登録する必要があります。 RegAsm は、登録されているアセンブリが PIA である各タイプ ライブラリ キーの下にレジストリ エントリを自動的に作成します。 たとえば、特定のアセンブリが ADODB タイプ ライブラリのバージョン 1.0、1.5、および 2.0 の PIA である場合、登録されたアセンブリをそのタイプ ライブラリの PIA として識別するエントリが各タイプ ライブラリ キーの下に作成されます。

Visual Studio の場合: ユーザーが PIA が登録されているタイプ ライブラリへの参照を追加しようとすると、Visual Studio では、Tlbimp を使用してタイプ ライブラリを再インポートする代わりに、登録済みの PIA が自動的に使用されます。 これにより、PIA が可能な限り使用されるようになります。

ユーザーが PIA が登録されていないタイプ ライブラリへの参照を追加しようとすると、PIA が存在しないことが警告され、PIA を取得するために MSDN サイトが参照され、その時点で Visual Studio がタイプ ライブラリをインポートする機会が提供されます。 Visual Studio でタイプ ライブラリをインポートすると、ユーザーは PIA をバイパスし、PIA 作成者が行った可能性のあるカスタマイズをバイパスします。 これはお勧めしません。

複数の PIA を 1 つのファイルに結合できますか?

Tlbimp は、複数のアセンブリを 1 つの PIA に結合する方法を提供しません。ただし、ILDASM によって生成された MSIL を他のアセンブリの MSIL とマージすることで、アセンブリを結合できます。 この方法を使用するには、MSIL の基本的な理解が必要です。

PIA にはどのような名前空間を使用する必要がありますか?

PIA の名前空間は、インポート時に定義されます。 既定では、名前空間はタイプ ライブラリ名 (タイプ ライブラリ ファイル名ではなく、タイプ ライブラリ内の名前) と同じです。 名前空間は、Tlbimp の /namespace オプションを使用して変更できます。

正しい名前空間を決定すると、混乱を招く場合があります。 次のような考慮事項があります。

  • 既存の Microsoft® Visual Basic® 6.0 コードでは、タイプ ライブラリ名によって型のスコープが設定されます。 たとえば、Visual Basic 6.0 では、ADO ライブラリは ADODB と呼ばれます。 既定の名前空間を使用すると、Visual Basic 6.0 アプリケーションのソース互換性が提供されます。既定の名前空間は元のタイプ ライブラリ名 (ADODB) と同じになるためです。
  • 今後使用できるライブラリのマネージド バージョンに対して"実際の" 名前空間を予約することもできます。 たとえば、Microsoft Excel チームは、名前空間 "Office.Excel.Interop" を使用して、より使い慣れた名前空間 "Office.Excel" を将来構築できるマネージド抽象化レイヤーに使用できるようにすることができます。
  • PIA のユーザーは、ソース コードで名前空間を参照する必要があるため、名前空間はわかりやすいものの簡潔にする必要があります。
  • 省略形は使用しないでください。

PIA にはどのようなファイル名を使用する必要がありますか?

アセンブリには、アセンブリ名、名前空間名、アセンブリのファイル名の 3 つの重要な名前が関連付けられています。 既定では、Tlbimp は、アセンブリがインポートされたタイプ ライブラリの名前 (つまり、ライブラリを含むファイルの名前ではなく、ライブラリ名) と同じ 3 つの名前をすべて持つアセンブリを作成します。 たとえば、foo.dllに含まれる FooLib タイプ ライブラリが Tlbimp と共にインポートされた場合、FooLib という名前のアセンブリは、fooLib という名前の名前空間を使用して、FooLib.dllという名前のファイルに作成されます。

Tlbimp によって作成されたアセンブリ名とファイル名は 、/out オプションを使用して変更できます。 名前空間は 、/namespace オプションを使用して変更できます。

インポートされたタイプ ライブラリの名前がライブラリを含むファイルと同じである場合、Tlbimp は入力ファイルを出力ファイルで上書きしません。 このような場合、ユーザーは /out オプションを使用して別の出力ファイル名を指定する必要があります。 この場合に使用される一般的な名前付け規則は、 を追加する方法です。相互運用」 をライブラリの名前に指定します。 たとえば、foo.dll という名前のファイル内のタイプ ライブラリ名 Foo は、Foo.Interop.dllにインポートされます。

PIA に署名するためのキーはどこで入手できますか?

PIA は、他のマネージド アセンブリの署名に使用されるのと同じ公開キーと秘密キーのペアで署名できます。 キーは、Microsoft® .NET Framework SDK の一部である SN ユーティリティを使用して生成できます。

PIA を開発者に配布操作方法。

PIA は、ベンダーが生成するアンマネージ コード ライブラリの一部として配布する必要があります。 PIA は、タイプ ライブラリが DLL または EXE で配布されるのとほぼ同じ方法で配布する必要があります。

PIA を発送後に変更または修正することはできますか?

はい。ただし、アセンブリのバージョン番号は、新しいバージョンが生成されるたびに変更する必要があります。

PIA の発行元ポリシーを作成できますか?

はい。発行者ポリシー、アプリケーション ポリシー、およびマシン ポリシーはすべて、アプリケーションが PIA にバインドされる方法を管理するために使用できます。

PIA を使用しない場合は問題ありませんか?

PIA が使用できない場合は、PIA ではない相互運用機能アセンブリ (代替相互運用機能アセンブリと呼ばれます) を使用する必要がある場合があります。 PIA アセンブリを使用できない場合は、アセンブリから代替相互運用機能アセンブリで定義されている型を公開しないようにする必要があります。 代替相互運用機能アセンブリの使用は、アセンブリで定義されている型が内部使用に制限されている場合にのみ使用できます。 アセンブリは、代替相互運用機能アセンブリから型を公開できません。 つまり、アセンブリに、代替相互運用機能アセンブリで定義されている型を使用するパブリック メソッド、フィールド、またはプロパティを含めることはできません。 アセンブリは、代替相互運用機能アセンブリで定義されているインターフェイスも実装できません。

Microsoft および Microsoft 以外の製品の PIA はどこで入手できますか?

一部の PIA は Microsoft Visual Studio .NET に付属しています。