問題タブ [com-callable-wrapper]

あいまいな主題で申し訳ありませんが、私はこの分野に不慣れで、より具体的なものを思いつくことができませんでした.

COM プラグインをロードするサードパーティ アプリケーション (VC++ 2005 で記述) をデバッグしています。私のプラグインは C# 4.0 で書かれています。プラグインの特定のメソッドが呼び出されると、アプリケーションがクラッシュしますが、かなり役に立たないコール スタックが表示されます。

これは、CCW に関連する問題があることを示していると思います。クラッシュの時点でアプリケーションがプラグインで呼び出すはずのメソッドも、実際には呼び出されません。NotImplementedException をすぐにスローするようにプラグインを変更しましたが、スローされません。ただし、同じインターフェイスの別のメソッドを変更して NotImplementedException をスローすると、アプリケーションはそのエラーを適切に報告します。

さらなるデバッグ戦略を推奨できる人はいますか?

.NET 3.5 C＃WinFormsアプリケーションに、5つのメソッドを持つクラスがあります。各メソッドは、C++COMインターフェイスの異なるセットを使用します。Marshal.FinalReleaseCOMObjectこれらのCOMオブジェクトのクリーンアップに使用しています。このコードは、この.NETプラットフォームで問題なく正常に機能します。ICOMInterface1しかし、このアプリケーションを.NET 4.0に移動すると、変数をからにキャストした行で、これらのメソッドの1つでこのエラーが発生し始めますICOMInterface2。

基になるRCWから分離されたCOMオブジェクトは使用できません。

また、を使用している行を削除してMarshal.FinalReleaseCOMObjectも、このエラーは発生しません。

ここで何が欠けていますか？また、これらのアンマネージCOMオブジェクトを.NET 4.0プラットフォームのメモリからクリーンアップするにはどうすればよいですか？

既存の COM コンポーネントを新しい機能に置き換えるために、概念実証の COM Callable Wrapper を作成しました。私のプロジェクトの制約は、呼び出しコードを変更できないことです。呼び出し元のコードは、COM 呼び出し可能ラッパーの存在を認識しない必要があります。私が作成した小さな概念実証ソリューションは、呼び出しコードが .NET 2.0 の場合は機能しますが、呼び出しコードが .NET 4.0 の場合は InvalidCastException で失敗します。この .NET 4.0 固有の原因を発見するのを手伝ってくれる人はいますInvalidCastExceptionか?

COM 呼び出し可能ラッパー:

呼び出しコード (new行で例外がスローされます):

gcroot<ManagedObject>.NET では、アンマネージ コードからのコールバックを提供するためにアンマネージ コードにマネージ オブジェクトを格納することに関して、比較的よく知られている問題があります。 「AppDomains 間で GCHandle を渡すことができません」というエラーが発生します。

この問題の標準的な修正方法は、デリゲートへの関数ポインターを使用することです。これは、デリゲートを使用して正しい AppDomain を「記憶」できるためです。http://lambert.geek.nz/2007/05/29/unmanaged-appdomainを参照-callback/で完全な説明が得られます。

ただし、このソリューションは少し複雑であり、デリゲートの有効期間を慎重に管理する必要があります。

管理対象オブジェクトに COM Callable Wrapper を使用しても同様に機能するようです: を格納する代わりにgcroot<ManagedObject>、ポインターをIUnknown *usingとして格納しGetIUnknownForObjectます。

GetObjectForIUnknown次に、コールバックを行う前に逆変換を行うことができます。IUnknown *欠点は、実際のオブジェクト型が失われ、後で次のようなものを使用してダウンキャストする必要があるため、型の安全性が少し失われることです。

はどこにm_valueありIUnknown*ますか?

私はそれを試してみましたが、私のユースケースではうまくいくようですが、このアプローチをとることで問題はありますか? デリゲート ソリューションを使用する可能性のある場所ならどこでも適用できるように思われるので、それについて何かが欠けているのではないかと思います。

以下を使用して、(ネイティブ コードから) COM オブジェクトを作成していますCoCreateInstance。

実際、私は Delphi を使用しています。つまり、ヘルパー関数を呼び出します。

ほとんどの場合、この関数は成功します。しかし、同じ実行可能ファイル、同じプロセスで、への呼び出しが次のように失敗することがあります。CoCreateInstance

関数を再度呼び出すと、成功する場合と失敗する場合があります。（明らかな）韻や理由はありません。

それは私のCOM dllではありません

これが私が作成した通常のCOM DLL であるOutputDebugString場合DLL_ATTACH、DllGetClassObject.

残念ながら、これは COM dll ではありません。これは .NET アセンブリ dll です。また、COM サブシステムは単に myを「ロード」dllするだけではありません。代わりに、COM は以下をロードするように指示されますmscoree.dll。

そしてmscoree.dll、必要な機能をエクスポートしGetClassObjectます。私ではなく、mscoree.dll戻ってきた人E_FAILもそうです。私の開発マシンでは障害が発生することはありませんが、顧客のマシンでは一貫して断続的に障害が発生します。

.NET ログを有効にするにはどうすればよいですか?

問題は、（有用なものではなく）mscoree.dll戻ってくるものなので、問題が何であるかを教えてもらうにはどうすればよいですか？E_FAIL

たとえば、(COM オブジェクトを頻繁に使用する唯一の顧客であることに加えて) 障害を経験している唯一の顧客は、たまたま Windows XP を使用しているようです。おそらく、.NET フレームワーク (バージョン 4 より前) で、異なるバージョンの .NET ランタイムを同じプロセスにロードできないという既知のバグが発生している可能性があります。

これを行うと、CLR バージョンの依存関係が導入され、ホスト プロセスが期待する CLR バージョンと競合する可能性があります。

この障害モードは、COM ラッパーを使用する場合の MSDN の記事にも記載されています。を指定するオプションがありclrVersionます。

別のバージョンの CLR が既に読み込まれていて、指定されたバージョンをインプロセスで同時に読み込むことができる場合は、指定されたバージョンが読み込まれます。それ以外の場合は、読み込まれた CLR が使用されます。これにより、ロード障害が発生する可能性があります。

これがWindows XP または .NET Framework の以前のバージョンでの断続的なロード エラーの原因である場合、どうすれば にそのmscoree.dllことを教えてもらえますか?

原因が別の場合、どうすれば .NET にそれを教えてもらうことができますか?

私のグループは .NET アセンブリを作成しました。これは VB2010 プロジェクトでうまく機能します。また、一部の関数を VB6 で使用できるようにしたため、COM Callable Wrapper を作成しました。これもテストしましたが、うまく機能します。最後のステップは、社内のユーザーに展開する方法を決定することです。どのファイルを展開し、どのように登録するかはわかっています。MSDN やその他の情報源を調べて、それらを展開する場所を探しています。

現在、ラッパー DLL、TLB、Interop DLL を {pf}\MyLib に展開しています。CCW を展開する場所に関するベスト プラクティスはありますか? これはCOMオブジェクトであるため、登録する必要があり、{sys}に入れる必要があると考えています。決定を下すために参照できる参考資料をいただければ幸いです。