プロジェクトの互換性設定を「互換性なし」から「バイナリ互換性」に変更することで、GUID（IIDのCLSIDのLIBIDなど）を再利用するようにVB6に指示できます。これらの設定は、[プロジェクト]->[あなた]-[プロジェクトのプロパティ]にあります。互換性の設定は、[プロジェクトのプロパティ]ウィンドウの[コンポーネント]タブにあります。3つの選択肢があります。
これがMSDNがそれらについて言っていることです：
互換性なし
この設定では、互換性は強制されません。Visual Basicは、プロジェクトをビルドまたはコンパイルするたびに、新しいインターフェイスIDとクラスIDを作成します。ビルドされた各バージョンは、コンポーネントの特定のビルドで動作するように作成されたアプリケーションでのみ使用できます。
プロジェクトの互換性
この設定を使用すると、プロジェクトを特定のコンポーネントプロジェクトと互換性のあるものにすることができます。新しいタイプライブラリ情報が生成されている間、テストプロジェクトがコンポーネントプロジェクトを参照できるように、タイプライブラリ識別子が維持されます。この設定は、テスト中に互換性を維持するためのものです。したがって、コンポーネントが解放されると、互換性なしの設定と同じように動作します。
バイナリ互換性
プロジェクトをコンパイルすると、VisualBasicは必要な場合にのみ新しいクラスIDとインターフェイスIDを作成します。以前のバージョンを使用してコンパイルされたプログラムが引き続き機能するように、以前のバージョンのクラスIDとインターフェイスIDが保持されます。互換性のないバージョンになるような変更を加えた場合、VisualBasicは警告を表示します。ActiveXコンポーネントの古いリリースバージョンとの互換性を維持したい場合は、これが使用する必要のある設定です。
現在、互換性なしでコンパイルしているようです。MSDNの記事に記載されているように、コンポーネントの新しいバージョンと古いバージョンの互換性を維持するには、バイナリ互換性を使用する必要があります。次の手順を実行することで、これを実行できます。
互換性なしで各プロジェクトを1回コンパイルします
これらの「クリーンな」バージョンを、ネットワーク共有など、ビルドを実行するユーザーが簡単にアクセスできるフォルダーに保存するか、ソース管理に配置します。
戻ってすべてのプロジェクトを「バイナリ互換性」に変更し、「互換性ファイル」をネットワーク/ソース管理に保存したばかりの対応するバージョンにポイントします（互換性ファイルをコンパイルしているのと同じパスにポイントしないでください互換性のあるファイルは、変更されない元のコンポーネントの別のコピーである必要があります。これは、VBが再コンパイル時にそのファイルからプロジェクトにIDをコピーできるようにするためにのみ存在します）。
プロジェクトを再コンパイルするたびに、互換性のある（元の）バージョンのコンポーネントのGUIDが再利用されます。
編集：ジョーがコメントで述べたように、クラスインターフェイスが変更されたとき（つまり、以前のバージョンとのバイナリ互換性を維持できるほどインターフェイスが変更されたとき）も認識する必要があります。これが発生した場合は、以前のバージョンのコンポーネントから完全に切り離す必要があります。新しい「クリーンな」バージョン（つまり、互換性なし）を再コンパイルし、その新しいバージョンを将来のビルドで互換性のあるファイルとして使用します。ただし、クラスインターフェイス（プロパティとメソッド）が変更された場合にのみ、最初からやり直す必要があることに注意してください。実際、プロジェクトが以前のバージョンのコンポーネントと互換性がなくなった場合、VBは警告を表示します。
あなたが端に住みたいなら...
私が働いている場所では、実際には正しい方法ではありませんが、ほとんどのプロジェクトで互換性なしを（乱用）使用する傾向があります（バイナリ互換性を使用する必要があります）。私たちの会社では、すべてのプロジェクトをコンパイルする自動ビルドツールがあり、ツールの主な機能の1つは、プロジェクト間の壊れたプロジェクト参照を自動的に修復できるため、怠惰になりました。ビルドツールがこれを修正するため、バイナリ互換性を使用するインセンティブが少なくなります。
バイナリ互換性が優れている理由（または...私たちがやるべきことをやるべきではない理由）
バイナリ互換性が通常より良い選択であるいくつかの理由：
マイクロソフトはそう言います
すべてのコンポーネントが以前のリリースのソフトウェアとバイナリ互換である場合は、単一のコンポーネントを簡単に再コンパイルして、顧客に再配布できます。これにより、バグ修正/パッチの展開が容易になります。プロジェクトで互換性なしを使用する場合、新しいコンポーネントは（おそらく）古いコンポーネントでは機能しないため、小さなパッチを送信する必要があるたびに、アプリケーション全体を再コンパイルして再配布する必要があります。
あなたはCOM標準を維持するために自分の役割を果たしています。COMでは、クラスIDとインターフェイスIDは、クラスまたはインターフェイスを一意に識別することになっています。クラスやインターフェイスがビルド間で変更されていない場合、それらのクラスやインターフェイスの新しいIDを生成する理由はありません（実際、同じクラスに複数のIDがあります）。Binary Compatiblityを使用すると、ビルド間で同じIDを維持できます。つまり、良き市民であり、COMの規則に従っています。
レジストリノイズが少ない。古いバージョンとバイナリ互換ではない顧客に常に新しいコンポーネントを展開している場合、新しいバージョンごとに新しい情報がレジストリに追加されます。特に、新しいインターフェイスとクラスIDはそれぞれ登録する必要があります。すべてをバイナリ互換に保つ場合、クラスIDとインターフェイスIDは変更されないため、インストーラーはレジストリキーを1か所に追加するだけで済みます。
他のサードパーティアプリケーションが消費しているパブリックAPIまたはコンポーネントを公開している場合は、コードに依存するサードパーティソフトウェアを壊さないように、バイナリ互換性を使用することをお勧めします。