com - タイプ ライブラリの GUID を変更する場合

Question

COM インターフェイスでメソッドを追加/変更/削除するときは、インターフェイス/コクラス GUID を変更する必要があることを知っていますが、タイプ ライブラリについてはどうでしょうか。タイプ ライブラリの GUID をいつ変更する必要がありますか? タイプ ライブラリ内の GUID が変更された場合、それを変更しますか? または、タイプ ライブラリ内に独自の GUID を持たないものが変更された場合にのみ変更する必要があります。

Answer 1

基本的な原則は、COM インターフェイスとタイプ ライブラリは不変 (つまり、決して変更してはならない) である必要があるということです。COM インターフェイス内の 1 つの項目を変更する場合、新しいバージョンは以前のバージョンとは完全に別のエンティティである必要があります。これを行う唯一の方法は、ライブラリ内のすべてのインターフェイスの GUID と、タイプ ライブラリ自体の GUID を変更することです。タイプ ライブラリの名前を変更することも (個人的な正気を保つために) 良い考えです。

理想的には、COM インターフェイスを変更しないでください。代わりに、新しい派生 COM インターフェイスを作成し、新しいタイプ ライブラリで発行します。

Answer 2

同様の質問があります。

GUID_A を持つ 1.0 タイプ ライブラリにインターフェイス IID_A を実装する CLSID_A を持つオリジナルのコントロールがありました。

後で、元のコントロールに新しいインターフェイスを追加することにしました。次に、IID_A と IID_B の両方のインターフェイスを実装します。おそらく同じ CLSID を保持する必要があると考えましたが、typelib 自体をどうするかについてはあまり知りませんでした。私は主に、QueryInterface を含む VC++ のプログラムによる本による作業を行っていましたが、バージョン管理やタイプライブラリについてはあまり気にしませんでした。特定の CLSID を使用してオブジェクトを作成する必要があり、CoCreated インスタンスを要求しただけです...そして、新しいインターフェイスの潜在的なサポートについてインターフェイスをクエリしました...

LabVIEW のような凝った環境や、Microsoft .NET のようなデザインタイムのドロップイン開発環境に入ると、MFC が壊れているように見えます。

あなたの回答で、すべての GUID を変更することについて言及しています。利用可能な機能に基づいてアプリケーションを適応させるというパラダイム全体が死んだのでしょうか?新しいアプリケーションは、古いバージョンのコントロールで基本的な機能を引き続き使用できますか? たぶん、私は後の波を捉えていませんでした: 古いコントロール バージョンを使用してアプリケーションを実行するように変更しても意味がありません。特定のコントロール バージョンが必要なだけです。それが、M$ が ASSEMBLY のものを出した理由でしょう。