これは通常のグッド プラクティスの範囲外であることに同意しますが、解決策または少なくとも何らかのガイダンスを探しています。– jJack 1時間前
展開ツールにアクセスすることはできませんが、視点を提供しようとします。あなたが書いた内容のすべての側面を完全に把握しているわけではないので、一般的なコメントになります。あなたが求めていることと少なくとも何か関係があることを願っています。書いていた通りのブログになりました。
私にとって、MSI パッチは2 つの基本的なシナリオに効果的です。
- マイナー アップグレード パッチを使用して、インストール済み製品のアンインストール シーケンスのエラーを修正します。
- いくつかのファイルのマイナー アップグレード パッチをリリースされた製品の "ホットフィックス" として提供しますが、これはサイズが大きく、再インストールに時間がかかる可能性があります。
これら 2 つの目的のために、私は専門的に MSI パッチを効果的に数回使用しました。いずれの場合も、他に適切な修正はありませんでした。私見のパッチ適用は「ホットフィックス」のためのものです。これは、頻繁な増分更新の展開ではなく、テクノロジー全体が設計されているものです。96 個のファイル アップデートの配信はホットフィックスではありません。
パッチは作業中のアップグレードです : パッチ適用は、既に機能しているアップグレードのためのよりコンパクトな配信メカニズムであることを忘れないでください。これは、メジャー、マイナー、または小規模な更新である可能性があり、それぞれの動作は異なります。他のことを行う前に、パッチとしてパッケージ化する前に、実際の完全なアップグレード MSI をテストしてください。これが私があなたにできる最善のアドバイスです。完全なアップグレードが正しく機能しない場合、パッチ適用に費やされたすべての労力が無駄になります。はい、これには、パッチ自体を作成する前のすべての対話でのインストール、アンインストール、およびアップグレードが含まれます。これは、おそらく最も一般的なパッチ適用の間違いです。
パッチのアンインストールを妨げる障害がいくつか存在します。アンインストール可能なパッチにつながる可能性のある技術的な問題が多数あります(読むことをお勧めします)。ホットフィックスを展開したパッチに欠陥があることが判明し、完全に取り戻さなければならない場合があるため、これは大きな問題になる場合があります。私の見解では、これは小さなパッチの主な用途の 1 つです。ロールバックできるクイック フィックスをデプロイします。
パッチ適用とカスタム アクション条件: 私にとって、パッチ適用の最悪の側面の 1 つは、通常のインストールとは対照的に、パッチ操作が実行されているときに、パッケージ内のカスタム アクションが実行されないように適切に調整されない可能性があることです。パッチには、 PATCHやMSIPATCHREMOVEなどのパッチ固有のプロパティがあります。カスタム アクションでこれらの条件を使用して、必要に応じてパッチ中に実行または実行しないようにします。カスタム アクションの条件には注意してください。正しく設定するのは複雑です。「 MSI条件チート シート」を参考にしてください。私はこれらの条件をテストしていません - テストが唯一の保証です.
さらなるパッチ適用のアドバイス:
- メジャー アップグレード パッチを完全に忘れてしまいます。私はそれらを試しましたが、もう一度試してみますが、理想的ではない傾向があります. メジャー アップグレード パッチが機能するための絶対要件は、InstallExecuteSequence で InstallFinalize の後に RemoveExistingProducts を配置することです。そうしないと、パッチ パッケージが既存のファイルにパッチを適用しようとする前に、ファイルがアンインストールされるからです。かなりキャッチ22。
- マイナー アップグレードでは、既存のインストールはアンインストールされませんが、評価者は新しい MSI ファイルを再キャッシュして、メンテナンスおよびアンインストール操作に使用します。これは、パッチを実行する前にアンインストール シーケンスを修正できることを意味します。実際、マイナー アップグレードが機能する場合、パッチはまったく必要ない場合があります。MSI ファイルが非常に大きく、小規模な「修正プログラム」を提供したい場合を除き、マイナー アップグレードを使用してください。
- パッチにファイルを含める必要がある場合は、「ファイル全体を含める」を有効にすることをお勧めします。それ以外の場合は、ビットレベルのパッチ適用が行われ、これは不必要に複雑になります (バイナリが巨大でない限り)。また、ビットレベルのパッチが署名付きファイルとデジタル署名でどのように機能するかもわかりません。
- 必要なものだけをパッチに含めます。不要なファイルや設定を追加せず、信頼できるパッチを作成できます。可能であれば、カスタム アクションを追加しないでください。
- 既に述べたように、パッチは通常のインストールと同じ InstallExecuteSequence を使用することに注意してください。ただし、カスタム アクションは、PATCHやMSIPATCHREMOVEなどのパッチ固有のプロパティを使用して、異なる方法で条件付けできます。カスタム アクションでこれらの条件を使用して、必要に応じてパッチ中に実行または実行しないようにします。
- コンポーネントの参照は、どのタイプのパッチでも機能するために 100% 正確でなければなりません。例外なく。
- マイナー アップグレード パッチは、setup.exe / update.exe 経由で配信されない限り、適切な msiexec.exe コマンド ラインで実行する必要があります。
- 私の経験では、サードパーティのマージ モジュールが原因でパッチの問題が頻繁に発生します。
- 彼らが言うように「バージョン嘘」 - ディスク上のファイルの MSI ファイルに異なるバージョンを追加することにより、ファイルが常に更新されるようにする黒魔術は、パッチ エラーを引き起こすようです。
- パッチは、メイン インストールと同じ GUI を表示します。私の意見では、これは誤った設計です。GUI のカスタム アクションは、パッチ適用プロセスを台無しにする可能性があります (パッチの値に対して新しいユーザー入力を受け入れる必要がありますか?)。
- 各パッチは累積的であるべきだと思います - 以前のパッチをすべて置き換えます。連続して順番にインストールされたいくつかのパッチをテストしたとき、これが正しく機能することはありませんでした。私は、多くの理由から、これはそもそも無駄なパッチ適用アプローチであると結論付けました。パッチファミリー、ターゲットリリースなどであなたが説明したとおりに問題がありました...パッチはあまりスマートではありません。それが属する製品を見つけようとするいくつかのファイルの複雑なバンドルです。
結論として明らかなことは、たとえ要求されたとしても、このパッチ適用アプローチを使用することは実際にはお勧めしないということです。ただし、Installshield の代わりに WIX を使用するように切り替えた人へのパッチ適用が成功したことを示しているように思われるこのスレッドを読みました。CodeProject のリンクもチェックしてください。
あなたの展開シナリオについては、私はそのすべての側面を完全に把握しているわけではありませんが、開発者は、パッチを介してライブ アプリケーションを現在の QA バージョンに変換するためのパッチを望んでいるようです? 私はこれに同意することは決してありません。そうしないと、シナリオは見た目とは異なるに違いありません。そもそもマイナー アップグレードまたはメジャー アップグレードを提供しなければならない場合、パッチを作成する労力はまったく無駄です。QA 用のソフトウェアを提供するには十分すぎるほどです。dev-branch を使用して個別の MSI を提供し、製品にパッチが適用可能であることをテストするために時々いくつかのパッチを作成することもできますが、パッチを使用して製品のインストーラーを内部に提供することは決してありません。それがあなたに求められていることかどうかはわかりません。
マイナー アップグレードとメジャー アップグレードを行います。できればパッチ以外の場合は後者を使用し、本当に必要なときにパッチを提供します。インストール時間が問題になる場合は、すべての開発者および QA PC でナイトリー ビルドが完了した後に、メジャー アップグレードを毎日スケジュールすることはできますか? （インストールを機能させるために必要な実行中のプロセスを強制終了することを含む）。あなたのシナリオが実際に何であるかについて、私が完全に軌道から外れているかどうかはわかりません。
アップグレードとパッチ適用のヒントについては、 Stefan Kruger のinstallsite.orgを確認してください。
アップグレードとパッチについては、このよく知られた Wix チュートリアルをご覧ください。そしてMSDN。