2

.NETアプリケーションからTLBIMP.EXEで作成されたCOM/DLLを呼び出すときに、アーキテクチャを理解するための支援が必要です。シナリオは次のとおりです。

メソッドやクラスなどを含むXYZ.DLLというDLLがあります。これでXYZ.DLLの周りに.NETラッパーを作成でき、.NETアプリケーションから参照できるInterop.XYZ.DLLを取得できます。

最初の質問は次のとおりです。.NETアプリケーションでInterop.XYZ.DLLのクラスからオブジェクトを作成し、そのクラスのメソッドを呼び出すと、元のXYZ.DLLが呼び出されますか？私が理解している限り、Interop.XYZ.DLLは元のXYZ.DLLのプロキシクラスの形式として機能するため、呼び出しを行うにはXYZ.DLLが常にシステムに存在する必要がありますか？

2番目の質問：TLBIMP.EXEを使用してinterop.XYZ.DLLを作成したとします。.NETアプリケーションが実行されているシステムで、XYZ.DLLファイルにパッチが適用/更新されます。私の仮定では、新しくパッチが適用されたXYZ.DLLで同じクラス/メソッドが使用可能である限り、アプリケーションは引き続き機能します。それとも私は間違っていますか？参照される相互運用されたDLLのこのパッチに対処する必要がある場合のベストプラクティスはありますか？

ありがとう ！

よろしくフランク

4

2 に答える 2

2

生成された Interop DLL に関するあなたの理解はほぼ正しいです。基本的には、.NET が理解できる用語で COM DLL を説明する一連のメタデータが含まれています。元の XYZ アセンブリが呼び出されるため、ターゲット システムに登録する必要があります。

2 番目の質問については、COM DLL がアプリケーションで使用しているのと同じインターフェイスをサポートしていれば、アプリケーションは引き続き動作するはずですが、新しい DLL に対して明示的にテストしていないため、バグが発生するリスクがあります。これは、完全にアンマネージ コードで記述されたアプリケーションの場合とまったく同じであるため、このシナリオで .NET を使用することで、これ以上複雑になることはありません。

于 2011-01-25T09:22:08.820 に答える
1

最初の質問は簡単です。これはラッパーであり、置換ではありません。この用語は RCW、Runtime Callable Wrapper です。

2 つ目は、仮定の状況です。一般に公開されている COM サーバーのインターフェイスを何も変更しない単純なバグ修正では、変更によってプログラムが壊れていないことを確認する以外に、ユーザー側で何もする必要はありません。ただし、パブリック インターフェイスを変更するには、インターフェイスとコクラスに新しい GUID を使用する必要があるというのは、COM の厳格な規則です。これは、DLL Hell を回避するために非常に重要です。このような変更は破損の検出を非常に困難にする可能性があるため、AccessViolation は珍しくありません。これをトラブルシューティングする適切な方法はありません。このような変更を行うには、Tlbimp.exe を再度実行する必要があります。GUID は相互運用ライブラリ宣言の一部です。アプリを再コンパイルします。

于 2011-01-25T12:04:08.217 に答える