0

簡単に言うと、私は VisualBasic 6 プロジェクトのメンテナーであり、ActiveX COM DLL を生成します。このプロジェクトは、組織内で内部的に使用される約 50 の他のソフトウェア パッケージによって内部的に使用されます。

過去数年間、リリースされた各 DLL のセマンティック バージョニング "MAJOR.MINOR.PATCH" に従い、リリースごとに一意の GUID を割り当ててきました。つまり、1.1.1 と 1.1.2 には別々の GUID があります。

問題なく動作しましたが、これにより、新しい GUID を参照して再コンパイルできるようにするためだけに、ソフトウェア パッケージのそれぞれが新しいリリースを必要とするようになります。これは、リリースのための内部プロセスにより、数十時間の工数を浪費します。

私の質問は、1.1.1、1.1.2、さらには 1.1.99 が同じ GUID を持つように、マイナー リリースごとに GUID を維持するのは「悪い習慣」でしょうか? 代わりに、メジャー リリースごとに GUID を作成する方がよいでしょうか?

これにより、新しいメジャーまたはマイナー リリースが作成されたときにのみ参照が変更され、それに依存するソフトウェア パッケージに必要な変更の数が減ります。

最後に、応答に役立つ場合、現在 DLL は MyActiveXDLL_vMAJOR.MINOR.PATCH.dll という名前になっています。

MINOR ごとの GUID を使用して、MyActiveXDLL_vMAJOR.MINOR.dll に切り替えます。

4

1 に答える 1

0

GUID を変更しないことでこれを行うことができます (クラス ビルダで設定でき、ソース ファイルをメモ帳で開くと表示される非表示の属性に保存されます)。重大な変更を行うこと。

重大な変更は次のとおりです。

  • インターフェイスの変更 (メソッド/プロパティの追加/変更/削除/並べ替え)
    • dispids、パラメーターの順序、パラメーター名の変更を含む
  • 削除されたインターフェース
  • 以前は機能していたが、現在は機能していないメソッド。(メソッドが使用されている場合のみ問題です。使用されなくなった場合は、非推奨にしてエラーをスローするだけで、取り除くことはできません)。

VB では、デフォルトで、自動生成された dispid、guid、およびインターフェイスに依存します。クラスビルダーを使用して、これらを特定の値に設定できます。

初期値は、以前のリリースで自動生成された値に設定できます。これは手動で行う必要があります。TLBVIEW でタイプ ライブラリを開いて、それらが何であるかを確認する必要があります。

于 2014-09-24T16:07:01.123 に答える