私たちのプロジェクトでは、asp.netアプリケーションでCOMを使用して、たくさんのDelphiコードを再利用しています。.NETでP/InvokeよりもCOM相互運用が優先されるのはなぜですか?
このよう:我々は、などアクセス違反、DLLのアンロード、に関するいくつかの問題を抱えているレガシーデルファイのdll =>デルファイCOMラッパー=>ネット相互運用=> asp.net(MVC)
...私が持っていますP/Invokeコードを介して従来のDLLを直接使用するように移植しました。
COMとP/Invokeに関するリソースを見ると、ほとんどの場合、COMを使用するためのアドバイスがあります。何故ですか?
- コードが常に
- 複数のバージョンは、例えば(サーバ上に並べて実行することができ、正しいDLLの代わりに最後に登録COMを使用します。チェックアウト:P /呼び出しは、次のような利点を持っていません:COM通信Iが30%の高速化を示して読んで(記事)
64ビットプロセスから32ビットのDLLにp/invokeできますか?私はそうは思わない。 – Bond
COMがP/Invokeよりも優先されることを示唆する参考資料をいくつか教えてください。私は、P/Invokeが利用可能な場合はより良い解決策であることに非常に同意します。 .NET BCLの内部構造のほとんどは、P/Invokeの観点からWin32 APIに実装されています。 COM相互運用機能を使用する理由は、選択肢がない場合のみです。 Officeアプリケーションとの相互運用性、COM専用のWindows APIパーツなどがあります。 – Govert
DLLを覚えていますか?正しいdllを使用する代わりに、同じ名前の使用可能な最初のdllファイルを使用します。 APIの変更は実行時まで検出されません。つまり、バージョン管理はすべて不可能です。関数自体の名前を変更せずに、古いクライアントと新しいクライアントの両方に役立つDLLを作成することはできません。 –