1

major.minor.update.build_number一般的なバージョン管理スキームを使用したいと考えています。次回の製品アップデートはバージョン 1.0.1 になります。

社内の構成管理メカニズムはリリース ビルドとデイリー ビルドを生成し、それらはすべて MSI として自動的にパックされます。開発者と QA は定期的にビルドをダウンロードし、バグ修正などを検証するためにテスト リグを更新します。

CM ビルドごとにbuild_numberフィールドがインクリメントされるため、ビルド バージョンは次のようになります。

1.0.1.001 // Release build  
1.0.1.002 // Daily build  
1.0.1.003 // Another Daily build  
1.0.1.004 // New Release build

私たちの問題は、ProductVersionが変更されないため、Microsoft のインストーラ テクノロジでは、これらの MSI をテスト リグで更新として実行できないことです。既存の製品を完全にアンインストールし、目的の MSI を再インストールする必要があります。

ProductVersion スタンプに関係なく、MSI を作成して更新を適用する方法はありますか?

私たちはInstallShieldを使用しています。私たちが望むことを可能にする代替のインストール技術はありますか?

ありがとう！

4

1 に答える 1

1

この状況では、マイナー アップグレードを実行できるはずです。メジャー アップグレードを行うことが目的の場合は、ProductVersion プロパティの最初の 3 つのフィールドのいずれかを変更する必要があります。

上流に泳ぐことが目標の場合、FindRelatedProducts と RemoveExistingProducts の間にカスタム アクションを挿入して、MSI の組み込み製品検出ロジックをオーバーライドする必要があります。基本的に、Msi API を使用して、インストールされている UpgradeCode の ProductCodes を見つけます。

個人的にオススメです

Major.Minor.Build.Patch なので、インクリメントされたビルド シーケンスは

1.0.1.0 1.0.2.0 1.0.3.0 1.0.4.0 1.1.5.0 1.1.6.0 1.1.7.0

.0 により、必要に応じてアセンブリを再構築し、パッチとして出荷する柔軟性が得られます。

于 2010-11-02T22:18:13.603 に答える