すべての人に良い一日を！ パッチを生成するためのシステムを作成したすべての経験と共有したいと思います（この言葉を使用している読者はご容赦ください）。 ここではwixについて多くのことが書かれており、読者は少し知っていると思いますが、パッチを作成する問題は何らかの形で回避されました。 当社では、主にサイズとロールバックの可能性のために、広く使用されています。
まず、遭遇した問題について説明し、次にパッチを作成するための基本情報について説明します。 また、このプロセスとソースコードを簡素化するための具体的な例、ユーティリティを使用して、第2部を実行します。
チャレンジ：
1.ロシア連邦の多くの地域の森林関連当局の多くの支部にインストールされている非常に専門的なデスクトップ製品があります 。 便宜上、この条件付き製品に名前を付けましょう。Ashとしましょう。
2.各サブジェクトごとに、バイナリの違いはありませんが、変更のないコンテンツファイル（マップ、レポートテンプレート、ベースデータベースなど）のインストールの独自のバージョンがアセンブルされます。
3.「暑い」シーズンでは、更新プログラムは1〜2週間に1回発行されます（突然何かが必要になります。 この場合、製品のバージョンが変更されます（ major 、 minorまたはbuildのいずれか）
4.いつでも、どのクライアントもアップデートとフルバージョンの両方を要求できます。 最小限のコストで状況から抜け出すことが必要です。
5. ClickOnceは適切ではありません。一部の政府機関は、奇妙なことに、インターネットに直接アクセスできないか、非常に悪いです。
6. Wix上ですべてを無料で作成します。
これらの条件（ポイント4！）では、トラフィックを節約し、毎回100 MBのフルバージョンを送信しないために、何度もパッチを作成することをお勧めします。
開発者の気まぐれがいくつかあります。
1.また、パッチをスキップする自由も必要です。つまり、たとえば、1回または2回の更新で更新できます。
2.可能な更新のスキームでは、この気まぐれは次のようになります。
つまり、すべてのシーケンスオプションが許可されます。
•すべてのパッチを一貫して受信してから、完全なmsi（実線）を取得します。
•2つのパッチをスキップし、3番目のパッチを適用すると、msi（破線）が理解できます。
•パッチを1つ入れ、1つスキップして、次のパッチを入れて、msiのフルバージョンを取得します。
•など
最初から始めましょう。
バージョンとパッチを扱います
ご存知のように、 Wixのバージョンは、xyz、x- メジャーバージョン 、y- マイナーバージョン 、z- ビルド番号の3つの数字で構成されています（=が考慮されます）。 私の意見では、これらの値を変更する原則は会社によって決定され、明示的なルールはなく、 推奨事項のみです。
同時に、3種類の更新があります。
- メジャーアップデート （より正確に-メジャーアップグレードですが、統一のためにメジャーアップデートを控えましょう）：
メジャーアップデートは、インストールされている機能の構造に影響を与えたり、コンポーネントの構成や名前を変更したりする包括的な製品アップデートです。 メジャーアップデートは、アプリケーションの以前のバージョンをアンインストールし、新しいバージョンをインストールします。 - マイナーアップデート （より正確に-マイナーアップグレードですが、統一のために、マイナーアップデートは脇に置きましょう）：
マイナーアップデートは多くのインストールリソースに影響しますが、 ProductCodeの変更を必要とするものはありません（詳細は以下をご覧ください）。 マイナーアップデートでは、新しい機能やコンポーネントを追加できますが、機能やコンポーネントのツリーを再編成することはできません。つまり、機能やコンポーネントを削除したり、ある機能から別の機能にコンポーネントを移動したりできません。 - 小さな更新 ：
小さな更新は、通常、いくつかのファイルに影響を及ぼし、その内容を変更する小さな更新です。
Wixのアップデートの「ベース」
Wixのリストされたアップグレードオプションの実装は、2つの変数に基づいています。
1. Product要素のUpgradeCode属性。
2. Product要素のProductCode属性。
Package.Idについては、
一言で言えば：
- 通常、1世代のUpgradeCode製品は変更されません。 システムが完全に書き換えられると、たとえば、適用される技術が根本的に変更されるとすぐに、UpgradeCodeが変更され、以前に作成されたすべてのサービスパックが切断されます。
- msiパッケージの名前が変更され、コンポーネントが削除または変更されると、 ProductCodeが変更されます。 新しいバージョンで既存のファイルが単に変更された場合、または新しいコンポーネントが追加された場合、ProductCodeは変更されません。
例
既にアプリケーションバージョン1.0がインストールされているとします。次のバージョンのインストールを作成しています。 その中で、 UpgradeCodeとProductCodeを以前のバージョンに関連する新しい値に変更できます。
これらの属性の値を古いままにして\を変更するとどうなるか見てみましょう。 （1）パッケージを作成し、（2）パッケージをインストールしようとした成功は、以下の表に反映されています。
*- マイナーアップデート 、**- メジャーアップデート 、***- 小規模アップデート
一般的なパッチ作成アプローチ
一般にパッチを作成する手順は非常に単純に見えます。1つ以上の「ベース」アセンブリと1つの「最終」アセンブリがあります。 パッチ生成ユーティリティは、「基本」アセンブリに含まれるバージョンから「最終」アセンブリに含まれるバージョンに製品を更新できるパッケージを作成します。
ご存じのように、Wixはパッチを作成するための2つのテクノロジーをサポートしています。PatchWiz.dllとWix自体を使用します。 これらのオプションのすべての長所と短所の分析には深く入りません。 これは記事の目的ではありません。 実験の結果、最初の選択肢に決着したとしか言えません（それだけで満足のいく結果が得られたからです）。
PatchWiz.dllを使用してWixにパッチを作成する
PatchWizを使用してパッチを作成するには（ msimsp.exeユーティリティを使用します）、少なくとも2つのインストールパッケージ（正確には2つのmsiファイル）とパッチ記述子（通常Patch.wxsというファイル）が必要です 。 それらに提供されるすべての可能性を詳細に説明することはしません。さもなければ、記事が大きすぎることが判明しますが、要点に触れます。 （詳細はこちらをご覧ください ）
1.最初のPatch.wxsが作成され、その中にPatchCreation要素が作成されます。
<PatchCreation Id="{42D7EE3B-A712-4AD4-9B23-A8710FC486FA}" Codepage="1251" CleanWorkingFolder="yes" OutputPath="patch.pcp" WholeFilesOnly="yes">
ここに：
Id-常に新しい、一意のIdパッチ。
コードページ-PCP拡張子を持つ中間ファイル（当社用）のコードページ。
CleanWorkingFolder-パッチを作成した後、一時フォルダーをクリーンアップします。
OutputPath-中間ファイルのパスと名前。
WholeFilesOnly-パッチには、変更されたファイルだけでなく、変更されたファイル全体が含まれます。
パッチに関する情報を持つ要素は、PatchCreation内に記述されています。ここでは、すべてが明確であると思います（PatchMetadataはオプションの要素です）。
<PatchInformation Description=" " Comments=" 1.1" Manufacturer=" "/> <PatchMetadata AllowRemoval="yes" Description=" " ManufacturerName=" " TargetProductName="" MoreInfoURL="http://./" Classification="Update" DisplayName=" 1.1"/>
そして、おそらく、主なもの：基本的なアセンブリと最後のアセンブリが存在するパスを示します。
<Family DiskId="2" Name="Yasen" SequenceStart="5000"> <UpgradeImage SourceFile="C:\Work\Yasen\v1.1\Setup.msi" Id="NewPackage"> <TargetImage SourceFile="C:\Work\Yasen\v1.0.8\Setup.msi" Order="2" Id="BasePackage1"/> <TargetImage SourceFile="C:\Work\Yasen\v1.0\Setup.msi" Order="3" Id="BasePackage2"/> </UpgradeImage> </Family>
ここに：
DiskId -Mediaテーブルの新しいエントリの番号。ベースインストーラーのメディア IDと一致してはいけません。
名前 -更新行の名前。 ファミリー名の異なるアップデートで1つの製品をアップデートしようとしたことはありません。
SequenceStart - InstallExecuteSequenceテーブル内のエントリの番号は、既存のエントリと一致してはなりません。 私が見たほとんどの例では、コストは5000です。この値は標準のWix値と競合しません。この値もパッケージでは使用されません。 （これに関する詳細は、上記のwix記事に記載されています）
Element UpgradeImage-最終的なアセンブリについて説明します。
SoureFile-最終アセンブリへのパス（実際には完全ではありませんが、「アンパック」バージョンでは、以下を参照）
Idはアセンブリ識別子です。
TargetImage要素-現在の更新で更新できるアセンブリについて説明します。
SourceFile-ベースアセンブリへのパス。
順序 -基本アセンブリの順序（なぜこれが必要なのか理解できませんでした）。
Idは、ベースアセンブリの識別子です。
そして、PatchCreationの最後に、PatchSequence要素が挿入されます
<PatchSequence PatchFamily= "Yasen" Sequence="1.1.0.0" Supersede="yes" ProductCode="{7381ABA7-774B-4D44-BD7B-0A90BBCF2B0A}" />
ここに：
PatchFamily-このパッチが属する行を示します（すでにどこかで見ましたか？）
順序 -パッチがリリースされた順序を区別するために、パッチのバージョンを示します。 xxxx形式で示されます
優先 -このパッチが以前のすべてのパッチを取り消すことができるかどうかを示します（累積パッチ？）
ProductCode-製品コード（間違えないように）。
組み立てと設置
インストールとパッチ記述子の準備ができたら、次を実行します。
1.次のように、すべてのインストールを個別のフォルダーに管理インストールします。
msiexec.exe /a 1.0\product.msi /qb TARGETDIR=C:\sample\1.0\admin msiexec.exe /a 1.1\product.msi /qb TARGETDIR=C:\sample\1.1\admin
PatchCreationのインストールパスは、たとえば「 C：\ sample \ 1.0 \ admin \ product.msi 」のような「アンパック」バージョンを指す必要があることに注意してください。
2. Wixファイルをコンパイルします。
candle.exe patch.wxs light.exe patch.wixobj -out patch.pcp
3. PatchWizのユーティリティを使用します。
msimsp.exe -s patch.pcp -p patch.msp -l patch.log
そして、ついに私たちが欲しかったものを手に入れました！
まとめ
しかし、問題を解決するために必要なパッチを入手しましたが、さらに何かが必要です。
- 毎回パッチファイルを作成する必要はありません。
- パッチのスキップを許可する必要がある場合、このシステムはうまく機能しません。 その理由は、このパッケージにパッチを適用できるバージョンを示し、5つのバージョンにパッチを適用したい場合、ボリュームが5倍になる可能性があるためです！ パッチのインストールとして以前のバージョンのみを指定すると、スペースは節約されますが、パッチをスキップする機能が失われます。
- パッチの収集に多くの時間を費やさないように、このプロセスを自動化する必要があります。
したがって、これらの不便を解決するために、第2部を書き、投稿の冒頭で約束したすべてを説明します。
参照：
Wixチュートリアル（非常に良いチュートリアル）
Wix-パッチの作成
MSDN-パッチとアップグレード