Visual Studio パッケージのIVsHierarchyインターフェイスには、メソッドUnused0
、、、、および次の説明があります。Unused1
Unused2
Unused3
Unused4
Adds new methods without recompiling or breaking binary compatibility.
誰かがこれをもっと詳しく説明できますか。これらの方法は正確にどのように役立ちますか?
Visual Studio パッケージのIVsHierarchyインターフェイスには、メソッドUnused0
、、、、および次の説明があります。Unused1
Unused2
Unused3
Unused4
Adds new methods without recompiling or breaking binary compatibility.
誰かがこれをもっと詳しく説明できますか。これらの方法は正確にどのように役立ちますか?
Visual Studio 拡張オブジェクトは COM で実装されます。COM の厳格な規則の 1 つは、インターフェイスは不変であるということです。インターフェイスを変更するには、インターフェイス IID を再割り当てする必要があります。インターフェイスを識別する GUID。これは、インターフェイスを使用するすべての人に多くの苦痛をもたらします. コードを変更して再コンパイルする必要があります。
この不変性要件が存在するのは、内部では COM インターフェイスがメソッド アドレスのテーブルとして実装されているためです。クライアントコードがテーブルの外観を想定しているものと、サーバーによって実装されている実際のテーブルとの間に不一致があると、災害が発生します。つまり、インターフェイスがバイナリ互換でない場合です。これにより、クライアント コードが間違ったメソッドを呼び出したり、関連付けられたメソッドがまったくないテーブル スロットを使用したりすると、実行時エラーの診断が非常に難しくなります。これは悪名高い COM DLL Hell 問題です。IID を変更すると解決します。クライアント コードは単に古い実装を見つけることができなくなります。それでも厄介なエラーですが、少なくとも診断は簡単です。
プレース ホルダーは、Microsoft がインターフェイスに新しいメソッドを追加できるようにするためにありますが、テーブル レイアウトを壊すことはありません。したがって、インターフェイスの名前を変更してインターフェイス IID を再割り当てする必要はありません。したがって、アドイン ベンダーにアドインの再コンパイルを強制することはありません。新しいアドインが古いインターフェイスの実装を使用しようとしない限り、それはまだ機能しません。ただし、厄介な AccessViolation ではなく、適切な例外メッセージが表示される可能性があります。