タイプライブラリのない32ビットATLCOMコンポーネントがあります。複数のインターフェースを実装する特定のクラスのクラスファクトリがあります。
これをインプロセスサーバーとして使用すると、すべてが正常に機能します。クライアント側がCoCreateInstance（）を呼び出し、オブジェクトがインスタンス化され、QueryInterface（）が要求されたインターフェイスへのポインターを取得します。しかし、コンポーネントをCOM +に入れると、クラスをインスタンス化できなくなります。CoCreateInstance（）はE_NOINTERFACEを返すようになりました。
問題は、タイプライブラリがないためにCOM+がマーシャリングを実行できないことだと思います。マーシャリングの方法がわかりません。これを解決するためにタイプライブラリを生成して登録する必要がありますか、それとも他の方法がありますか？
タイプライブラリはマーシャリングをサポートする 1 つの方法であり、プロキシ/スタブ DLL (IDL から生成される) は別の方法です。ただし、どちらの場合も、最初に IDL が必要です。
Microsoft がこのインターフェイス用の typelib/proxy DLL または IDL を提供していない場合、これには理由がある可能性があります。インターフェイスがマーシャリング不可能なデータ構造を使用している可能性があり、関数ポインターをメソッド パラメーターとして渡す必要があるか、またはこのようなものでしょうか? この場合、このインターフェイスを DCOM で機能させる方法はありません。
IDL を再構築することはできるかもしれませんが、それは不可能です。次に、最後のフォールバックは、カスタムまたはハンドラーのマーシャリングを使用することですが、おそらくそれは努力する価値がありません. そうは言っても、DCOM 用に設計されていない DCOM 用のインターフェイスを使用しない他のルートを検討することをお勧めします。
ウルク。microsoft.public.vc.atlで質問することをお勧めします。より多くの専門家が見つかると思います。(私は専門家ではありませんが) この問題は、登録されたプロキシ/スタブの問題よりも COM+ との関係が少ないと思います。(つまり、アウトプロセスでコンポーネントにアクセスする独自の COM クライアントを作成したとしても、同じ問題に遭遇する可能性があります) 標準のオートメーション互換インターフェイスを使用している場合、Windows はオブジェクトをマーシャリングする方法を知っています。大丈夫。しかし、それ以外の場合は混乱します。
タイプ ライブラリがないと、プロキシ/スタブを登録するか、IMarshal を自分で実装してカスタム マーシャリングを処理する必要があります。（または、私が理解できないこの「ハンドラーマーシャリング」もあります）
タイプ ライブラリがない理由 (Microsoft によって既に定義されているインターフェイスを実装しているが、typelib を持たないもの) を持っていない理由についてのあなたのコメントは、私に赤い旗を上げます。詳細を教えていただけますか？それが .DLL または .EXE 内のものであるが、型情報が (外部の .TLB ファイルではなく) ライブラリ自体の内部にある場合、すべてを機能させるために適切な情報を抽出することはおそらく可能です。処理する。
(記録として、Java を支持して ATL/COM プログラミングをやめたので、過去に覚えていることをお伝えすることはできますが、現在はツールを使用しておらず、元に戻すのは難しいでしょう。しかし、microsoft.public.vc.atl の人々は非常に賢いです)。