問題タブ [midl]

私は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の両方をロードするため、これは必要ありません。このシナリオでは、複数のタイプライブラリで同じインターフェイス定義が検出されると、アクティベーションコンテキストの生成が失敗します。

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

私の問題は単純ですが、解決方法がわかりません。COM タイプ ライブラリを生成するための idl ファイルを含む Visual Studio 2010 プロジェクトがあります。このプロジェクトは、もともと VC++ 6.0 によって作成されました。VC 6.0 は、このプロジェクトをエラーなしでコンパイルできました。しかし、最近それを変換し、VC 2010 でコンパイルしようとし続けています。常に次のコンソール出力メッセージが表示されます。

これは、MIDL が "C モード" でコンパイラを呼び出し、"C++ モード" では呼び出さないことを意味するだけであることを既に理解しています。プロジェクトには .c も .cpp も含まれておらず、.h ファイルと .idl ファイルしかありません: C/C++ セクションはプロジェクト プロパティ ページで使用できません。欠落しているセクションを利用可能にし、C++コンパイラをデフォルトにできるようにするために、dummy.cppファイルを追加しようとしました。

Midl ファイルは次のようになります。

MIDL に "C++ モード" でコンパイラ/プリプロセッサを強制的に呼び出すにはどうすればよいですか?

ATL COM サービスがあり、.IDL ファイルで次のように列挙型を宣言しました。

Gourmet.idl 内

ヘッダー ファイルが自動的に生成され、Gourmet_i.h が作成されます。

同じ ATL COM プロジェクトの別の .CPP ファイル (Decadence.cpp と呼びましょう) に、Gourmet_i.h を #include します。この .CPP にクラスを実装しました。これは名前空間「Chocolate」の下にあります。

Decadence.cpp の例:

コンパイルすると、Gourmet_i.h に関する次のエラーが表示されます。

これは、IDL の列挙型がグローバル名前空間で定義されているために発生することがわかりますが、この定義を含めることは可能であり、グローバル名前空間を汚染しないため、この競合は発生しませんか?

私はいくつかの MIDL ファイルを含むプロジェクトを持っていますが、VS は変更されていないにもかかわらず常に再コンパイルします。プロジェクトディレクトリをインクルードパスに入れるなど、いくつかのヒントを試しましたが、何も役に立ちません。問題は、他の「サブプロジェクト」の再コンパイルに影響を与えるヘッダー ファイルが生成され、コンポーネントの不要な再構築が発生することです。

これに対する回避策はありますか? カスタム ビルド ツール (midl.exe を使用) を使用してみましたが、これは通常、他の種類の問題に対しても機能しますが、midl.exe を使用するとまったく同じ動作を示します。つまり、MIDL は常に再コンパイルされます。

ちょっとイライラ...

私は、使用しているコア C# アプリケーションの依存関係である Microsoft Visual C++ COM プロジェクトを継承しました。プロジェクトを再コンパイルし、(tlbimp を使用して) 相互運用 DLL を再生成すると、OLE_HANDLE を受け取るライブラリ内のいくつかのメソッドが、以前のバージョンの相互運用 DLL から署名を変更します。

以前の相互運用性が生成されたとき、私は周りにいませんでしたが、Windows Server 2003 / Windows XP 上の VS2005 でコンパイルされたことはほぼ確実です。私のワークステーションは現在、Visual Studio 2010 (x64 用の C++ Visual Studio Compiler バージョン 16.00.40219.01) を使用する Windows 7 です。

これは、元の DLL と新しい DLL (ILSpy を使用) 用に生成された C# インターフェイスです。

新しいインターフェイス(2 番目のパラメーターは、ComAliasName 属性を使用してマーシャリングされ、int として):

古いインターフェイス(2 番目のパラメーターは uint):

私が見る限り、入力 IDL ファイルは変更されておらず、OLE_HANDLE の定義に影響を与える #includes / 条件付きステートメントもないようです。

問題のメソッドが呼び出されるたびに、AccessViolationException がスローされます。

生成されたインターフェイスが変更された理由 (MIDL/TLBIMP の変更によってこの動作が発生するかどうかわからない) や、これをさらにデバッグする方法を知っている人はいますか?

ヘッダ：

メソッドの C++ ソース:

照会する特定の/カスタム インターフェイスを備えたいくつかの directshow フィルター (COM) を含む .dll があります。

ほとんどのサード パーティの directshow コンポーネントには、クロス環境通信 (C# typelib インポート) に使用できる埋め込み .tlb ファイルが含まれています。

idl/tlb ファイルが提供されていないため、c# に必要なインターフェイスを手動で作成する必要はありません。

COM .dll から tlb (または、少なくとも MIDL でコンパイルできる idl) を生成することは可能ですか?

ITestローカル プロセスでのみ実行されるテスト スイートの一部であるCOM インターフェイスを作成しています。私がテストしている特定の機能は重要ではありませんが、主なポイントはCoCreateInstance()、バッキング オブジェクトをインスタンス化し、インターフェイスへのポインターを取得するために、またはファクトリ オブジェクトを使用しないということです。次のような単純な関数を呼び出すだけです。

明らかに、COM が提供する機能全体のかなり最小限のサブセットのみが必要です。

それを念頭に置いて、ここで私の質問です。

nul特定のファイルを生成しないように指示する方法として使用できることを理解してmidlいます (たとえばmidl itest.idl /iid nul、IID ファイルの生成を抑制するため)。ITest上記の単純な関数を介してインターフェイスをサポートするオブジェクトをインスタンス化するだけで、それをローカル プロセスでのみ使用する予定の場合、midl実際に必要な出力ファイルの最小のサブセットは何ですか?

C++ ライブラリがあり、そのライブラリの COM インターフェイスを自動生成しています。そのため、IDL ファイルを自動生成したところ、すべて正常に動作していました。しかし、COM にさらに多くのインターフェイスが追加されると、エラーが発生し始めました。

VS2008 と VS2010 の両方でこのエラーが発生しています。

この問題を解決する方法を教えてください。インターネット全体を検索しましたが、適切な解決策が見つかりませんでした。Microsoft Connectで報告されたバグが 1 つありますが、ステータスはクローズされています。彼らが提案する回避策の 1 つは、IDL ファイルを分割することです。これは、私の場合は不可能であり、インターフェイスが相互に依存しているためです。

サンプルの IDL ファイルSampleGenerated.idlをアップロードしました

midl へのコマンド ラインは次のとおりです。