たとえば、IWebBrowser2 は基本的に IE 用に作成された COM インターフェイスです。ただし、.NET プログラムで直接使用できる Microsoft.ShDocVw.dll の .NET で同じインターフェイスが定義されています。IUnknown、IInternetSecurityManager、IObjectSafety、IObjectWithSite などの型には、.NET インターフェイスをエクスポートするアセンブリがあります。プログラム内の既存のインターフェイスを再定義したくありません。もしそうなら、彼らは将来紛争を引き起こすかもしれません。
問題は、どの Microsoft の .NET アセンブリがこれらの COM インターフェイスを定義しているのかということです。
しかし、同じインターフェースが.NETで定義されています
.NET では定義されていません。shdocvw.dll への参照を追加することで取得できます。Visual Studio は、その DLL に埋め込まれているタイプ ライブラリを読み取り、そこから相互運用ライブラリを生成しました。Tlbimp.exe と同じことです。これが、COM 相互運用が基本レベルでどのように機能するかです。
.NET フレームワーク アセンブリで既に宣言されている COM インターフェイス型がいくつかあり、そのほとんどは System.Runtime.InteropServices.ComTypes 名前空間にあります。.NET 自体が作業を完了するために必要な非常に基本的なもの。これらは MSDN で文書化されているため、MSDN をすばやく検索するだけでそれらを見つけることができます。そして、.NET ラッパー クラスを機能させるためだけにあるinternalのものがたくさんあります。参照ソースまたは逆コンパイラでしかそれらを見つけることができませんでした。それ以外の場合は、コピー/貼り付け以外には役に立ちません。
COM インターフェイスの型を自分で宣言することは危険な冒険であり、常に避ける必要があります。小さな間違いが原因で、実行時エラーの診断が非常に困難で困難になります。またはエラーなし、最悪の種類。shdocvw.dll で行ったように、タイプ ライブラリがある場合は常にインポートすることをお勧めします。タイプ ライブラリは、間違いを避けるように設計されています。タイプ ライブラリがない場合は、グーグル コードが次善の策です。もちろん、SOでそれについて尋ねます。
Microsoft コードを含め、COM インターフェイスのほとんどのコンシューマーは、それらのインターフェイスの独自のプライベート定義を定義します。プライベートなので、使いたくても使えません。インターフェースを自分で実装していない限り、競合や問題が発生することはありません。COM インターフェイスを自分で実装していて、.NET コードから呼び出されることが予想される場合は、呼び出し元が使用しているインターフェイスと同じ定義を使用する必要があります。