問題タブ [coclass]

COMや剰余類についての知識があまりないので、なぜnewインターフェイスで演算子を使用できるのかよくわかりません。言語/フレームワークにとらわれない観​​点から、これが正しくコンパイルおよび実行される理由は混乱しています。

Visual Studio 2010で検査Applicationすると、次のことがわかります。

舞台裏で何が起こっているのですか？

私は COM を初めて使用します。インターネットで調べて、C++ で COM クラスを作成する方法を見つけました (C# で使用するため)。.idl ファイルに、次のようなものを配置する必要があることがわかりました。

私の質問は、CTopologyQuery クラスをどこで定義するかということです。別のファイルで通常の C++ クラスとして定義した場合、コンパイラはクラスをインターフェイスに正しくリンクしますか? C++ クラス コードは次のようになります (.cpp ファイルに実装されています)。

今のところ、ライブラリ セクションを .idl ファイルに入れても、入れなくてもコンパイルされます。ここで何をするのが良いのか、少し迷っています。コクラス定義がインターフェイスにデフォルトの実装を与えることになっていることは理解していますが、私にとってはメソッドのない空のクラスのように見えます...

私たちが使用しているサードパーティのライブラリで、次のようなコードを見つけました。

これは正確に何をしているのですか？msdn のドキュメントは、私が従うのに十分なほど主題を照らしていませんでした。

私は最近、インターフェイスを で修飾してデフォルトの実装を指定することにより、C# でインターフェイスを「新しく」できることを発見しました。CoClassAttribute

この機能が主に COM 相互運用機能をサポートするために存在することは承知していますが、これが汎用クラス ライブラリの既定の実装にインターフェイスを関連付ける合理的な方法であるかどうか疑問に思っていました。

2 つの質問があります。

1. これを行う際に落とし穴はありますか？私は COM 相互運用の専門家ではないので、これが POCO に悪影響を与えるかどうかはわかりません。私は主要なテストを実行していませんが、私の例の IL は問題ないようです ( andの呼び出しではなく、通常のnewobj命令です)。FooImplType.GetTypeFromCLSIDActivator.CreateInstance

2. これがスムーズに機能する場合でも、これを回避する他の理由 (API 設計の観点から言う) はありますか?

実際、ほとんどの場合tlbimp がインターフェイスを coclass に変換する機能です。具体的には、IDL にある場合

tlbimp は、それが実装する唯一のクラスであることを確認するためFirst、IFirst.NET インターフェイスを作成します。interface IFirstclass First

これはおそらく何らかの方法で役立ちます。

これはどのように役立つでしょうか？class Firstとにかく同じメソッドを持つことになるためinterface IFirst、何も追加されないため、その変換がなければ、interface IFirstどこにでも渡してまったく同じ効果を得ることができます。この変換の用途は何ですか?

私はVSTOライブラリを主に楽しみのために見てきましたが、と呼ばInspectorれるものがあることに気づきましたInspectorClass。

違いは何ですか、なぜそこにあるのですか、そしてどのようにそれを使用することができますか？（注：これらのクラスを使用してコーディングする方法についての答えを探しているのではなく、特定のアーキテクチャパターンの背後にある理論的根拠を探しています。純粋に学術的な好奇心です。）

私はCOMに比較的慣れていないので、これがばかげた質問である場合はお詫びします。一連のCOMインターフェイスをタイプライブラリAにコンパイルしています。このタイプライブラリは、私のソリューションのDLLの1つ（ a.dll ）のリソースです。別のDLL（b.dll ）に入る別のタイプライブラリ（B ）で、タイプライブラリAのインターフェイスを実装するコクラスを定義したいと思います。私が考えていることの簡単な例として、以下のIDLコードを参照してください。

上記をコンパイルできますが、MIDLによって生成されたtlbファイルをoleviewで開くと、エラーメッセージが表示されますTYPE_E_CANTLOADLIBRARY。やりたいことができないのではないかと思い始めています。これまでの私の実験では、タイプライブラリには、コクラス定義自体とともに、コクラスが実装するすべてのインターフェイスが含まれている必要があることが示唆されています。これは本当ですか？

ステートメントを削除するとimportlib("MyLibA.tlb);、コンパイルされたtlbファイルをエラーなしでoleviewで表示できますが、MyLibB.tlbにはインターフェイスの定義も含まれていIMyInterfaceます。つまり、インターフェイスは両方のタイプライブラリで2回定義されています。私のアプリケーションでは、登録不要のCOMを使用してa.dllとb.dllの両方をロードするため、これは必要ありません。このシナリオでは、複数のタイプライブラリで同じインターフェイス定義が検出されると、アクティベーションコンテキストの生成が失敗します。

別々のタイプライブラリで目的のインターフェイスとコクラスの分離を実現する方法についての提案はありますか？