7

ツールを使用して基本タイプ ライブラリをインポートすると、tlbimp.exe常に各 のインターフェイスが作成されますcoclass。たとえば、この IDL 記述

interface IFoo : IUnknown
{
    HRESULT DoSomething();
}

coclass Bar
{
    [default] interface IFoo;
}

結果:

  • COMインターフェイスIFooの表現としてのインターフェイス、
  • BarClassCOM コクラスの表現としてのクラスと
  • Barで注釈が付けられたインターフェイスCoClassAttribute。

Barとの GUIDIFooが等しい場所。MSDNは、このトピックについて次のように述べています。

このインターフェイスは、コクラスの既定のインターフェイスと同じ IID を持っています。このインターフェイスを使用すると、クライアントは常にイベント シンクとして登録できます。

それが私がこのトピックで見つけた唯一のものです。CoClassAttributeにより、インターフェイスを使用して実際のクラスのインスタンスを作成できることを知っています。BarClassまた、(実際には) を使用してクラスの新しいインスタンスを作成できることも知っています。私が理解していないのは、イベント ソースが定義されていないため、イベント シンクを接続できないBar場合でも、インポート プロセスがインターフェイスを生成する理由です。coclass

Barこの例でインターフェイス1を削除することは可能でしょうか、それともまだ考慮していない他のリスクがありますか?

1 たとえば、相互運用アセンブリを分解します。

4

1 に答える 1

6

名前を間違えたので、何が起こっているのか理解できません。Barタイプ ライブラリのコクラスは、BarインターフェイスとBarClassクラスを生成します。「FooBar」はありません。

これは、コードの移植を容易にするためにタイプ ライブラリが自動生成する追加の接着剤です。VB6 コードにとって特に重要なのは、COM オブジェクト モデルに多くの自由が必要だったことです。VB6 プログラムは、実装された実際のクラスであるかのように、コクラスを使用します。COM にはそのようなものは存在しません。コクラスはクラスの不透明なプレースホルダーであり、すべての作業を行うインターフェイスです。VB6 はインターフェイスの概念をサポートしていなかったため、コードで COM を直接モデル化することはできませんでした。

VB6 コンパイラ自体は、コード内の Class キーワードからコクラスを生成し、実際のメソッドとプロパティを運ぶインターフェイスを生成します。そのインターフェイスはhiddenです。クラスと同じ名前ですが、先頭にアンダースコアが付いています。慣例により、オブジェクト ブラウザはインターフェイスを非表示にします。したがってBar、VB6 で記述された場合、コクラスは_Barインターフェイスを生成します。

したがって、変換された VB6 プログラムはBarどこでも使用されます。「Bar」が「IFoo」に置き換えられない限り、これはコンパイルされません。合成Barされたインターフェイスが助けになり、その必要がなくなります。

まだ 2 つの解決すべき問題が残っていますが、合成BarClass型によって修正されています。 New Bar()インターフェイスのインスタンスを作成することは合法ではないため、コンパイルされません。コンパイラはその問題を解決し、自動的に "Bar" を "BarClass" に置き換えます。これは [CoClass] 属性の実際の役割であり、インターフェイスに関連付けられたクラスの名前を提供します。イベントは問題であり、ディスパッチ インターフェイスによって COM に実装されます。ここでも、イベントをサブスクライブする内部の複雑なメカニズムを備えた別のインターフェイス (IConnectionPoint など)。合成 BarClass は、それらを真の .NET イベントにします。

于 2014-01-03T16:27:25.520 に答える