第二のバージョンは、配置されたファイルの一つを新しいバージョンで置き換えるためのものです。対して加えられていることは言うまでもありません。>製品のどのバージョンをこのアップグレードによって置き換える予定なのか、ということについての記述も必要です。タグは、更新対象となるバージョンの詳細を記述しています。インストーラに、前の製品を削除しないように指示しています(思い出してください。私たちはマイナー・アップグレードをやっています。製品の古いバージョンを維持しながら、ファイルを一つだけ置き換えるのです。インストールするでしょう)。このアップグレード・パッケージで更新することになるバージョンの範囲を示しています。ものだけを探すことを意味します)。明解さと自己完結的な説明性のためには、省略せずに書く方が良いでしょう。訳註:実際にここで探そうとしているのは、更新する対象のバージョンではありません。なくて、更新する必要のないバージョン、すなわち自分自身(SELFFOUND)、および、更新してはいけないバージョン、すなわち自分よりも新しいバージョン(NEWERFOUND)を探そうとしています。直後に走るようにスケジュールされます。タグの中で、スケジュールを変更することも出来ます。タグの中を全部見て、リスト・アップされている全てのバージョンを探します。常に指定することが重要だという意味がこれで分ったでしょう。属性を指定することが可能です。言語識別子の数値を使って下さい。該当する言語の製品だけを探します。私たちは、チェックが走った後で、関連するプロパティの存在および値に基づいて、適切な行動を取ることが出来ます。新しいバージョンが既にインストールされています。ファイルをダブル・クリックするだけでは走らせることが出来ません。いうエラーが出るのです。コマンド・ラインから起動しなくてはならないのです。REINSTALLMODE=vomusどうやってこんな事を平均的なユーザーにやって貰おうか、などと尋ねるのはやめて下さいね。ラッパー・シェルをひねり出したりする方が良いですよ。ご覧のように、このアップグレード・バージョンは双方向に正しく動作します。以降に)更新されていた場合でも、対処出来ます。ダウングレードして戻すようなことはしません。絶対確実に間違いが無いようにするためには、このことは前もって計画しておかなくてはいけません。初めに出荷するインストーラであっても、このセーフティー・ロックが組み込まれていなくてはなりません(その事を現在のサンプルの古い方のバージョンで確認して下さい)。新しいバージョンが既にインストールされています。訳註:この章で説明されている「セーフティー・ロック」機構は、実際には、プロダクト・コードが異なるパッケージ同士の間でなければ、期待している通りの動作はしません。よってパッケージを起動する必要があることは、本文で述べられている通りです。メンテナンス・モードで走ることになります。何もせずに帰ってきてしまいます。実行されることは決してありません。インストーラを上記のコマンド・ラインで起動すると、何の警告も表示せずに、最後まで走ってしまうのです。ファイルのバージョン番号(ファイルにバージョン番号がある場合)や更新日付を見て、ファイル単位でダウングレードを防止しますので、致命的な実害は生じません。実際の動作と、ユーザーに対するフィードバックとの間に無視できないズレが生じますので、気持ちが悪いことは否定できません。プロダクト・コードが異なるパッケージ同士の間では、この「セーフティー・ロック」機構が有効に働きます。設定することと、バージョン番号をそれに応じたものに変更することだけです。現在のバージョン番号を指定することが出来ます(ただし範囲には含めません)。このようにすると、最初のバージョンから、現在の一つ前のバージョンまでのすべてのものが、現在のバージョンをインストールするときに自動的に削除されます。この同じインストーラを最初に使うインストーラとして使用することも出来る、ということにも注意してください。前のバージョンを見つけた場合は、前のバージョンを削除して現在のものをインストールします。クリーンなシステムで起動された場合は、単に現在のバージョンのアプリケーションをインストールするだけです。アップグレードのインストーラとフルセットのインストーラを個別に作る必要はありません。/></Upgrade>前のバージョンの削除は完全に自動的に行われます。プロパティを条件にしたカスタム・アクションを書いて対応することが出来ます。自動的な削除が行われるときにだけ、このプロパティを設定します。プログラムの追加と削除によってアプリケーションが手作業で削除される場合には、このプロパティを設定しません。中にスケジュールする必要があります。実際、そうしないと、コンパイルが通りません。スケジュールするタイミングとしては、以下の四つの選択肢があります。ドキュメントには、第四の位置が最も効率的であると述べられています。場合は、新バージョンをインストールした後に旧バージョンをアンインストールします。このとき、新旧ともに同一のパスを持つファイルが有る場合は、インストール時には上書きで更新し、アンインストール時には削除しないようにします。コンポーネントに対する参照カウントを使うことによって実現しています。従って、メジャー・アップグレードにおいても、コンポーネントの一貫性は非常に重要です。以前と同じままにしたりすると、コンポーネントに対する参照カウントと実際のファイルとの関係に食い違いが生じて、インストールしたはずのファイルがインストールされていなかったり、削除した筈のファイルが孤児となって残っていたりする結果になることがあります。前章で取り上げられたスモール・アップデートおよびマイナー・アップグレードが、作成においても使用においても、いろいろと厄介な問題がある形式だということを考えると、プログラムの更新を配布する最も手軽で現実的な方法は、ここで説明されているメジャー・アップグレードであると言って良いでしょう。旧バージョンから新バージョンへの移行時にどうやってユーザー・データを保護するか、という問題は残ります。前章で説明された「セイフティー・ロック」機構は、メジャー・アップグレードでは有効に機能します。本文では、自分より古いバージョンを探して置き換える、ということだけをやっていますが、自分より新しいバージョンが見つかればメッセージを表示して動作を中止する、ということも積極的に行うべきでしょう。「自分自身と同じバージョンが既にインストールされている場合にアップグレードを中止する」という機能は、実装しても働きません。同じなので、メンテナンス・モードで動作することになり、バージョンの比較は行われません。リンクする必要があります)。パッチワーク更新しなければならない小さなファイルが一つか二つ混じっているというだけの理由で、何メガバイトものファイルを入れたアップグレード・インストーラ・パッケージを作ることは、あまり効率的だとは言えないでしょう。従来から、そういう場合には、いつでも、パッチの方が良い解決策でした。パッチは、基本的には旧バージョンと新バージョンの異なる部分を入れたもので、ユーザーのコンピュータにある古いファイルを魔法のごとく自動的に新しいものに変えることが出来るものです。パッチ・パッケージには新規に配置するファイルを入れることも出来ます。ファイル)を作成することが出来ます。パッチ・インストーラ・パッケージは、二つの通常のインストーラ・パッケージ(一つは、バグのある古いファイルを持つ元のパッケージ、もう一つは、修正されたファイルを持つ新しいパッケージ)から作成されます。中には、ユーザー・インタフェイスを持たない非常に簡単な二つのインストーラ・パッケージが入っています。両方ともファイルを一つだけインストールしますが、そのファイルが元のバージョンとパッチを当てられたバージョンで変ります。ソース・ファイルの詳細は、もう今では、完全に見慣れたものになっている筈です。ファイルの参照だけです。/>パッチは第三のソース・ファイルから作成されます。ファイルですが、その内容は今まで書いたファイルとは異なるものです。ユーザーが後でパッチをアンインストールすることが出来るかどうかを決定します。タグが、パッチを適用される項目を包み込んでいます。大きくなくてはいけません。このパッチが同じファミリーに属する以前のすべてのパッチに取って代るものであるか否かを決定します。ビルド作業は以前のプロジェクトよりも少し複雑になります。最初に、ベースになる二つのパッケージを通常の方法でビルドします。二つとも、それ自身のフォルダに入れます。使って、二つのインストーラ・パッケージの間のトランスフォームを作成します。使うように指示を与えます。リンカに対してこのファイル形式で出力するように指示する必要はありません。リンカ自身がソース・ファイルの内容に従って出力形式を自動的に決定します。パッチ・パッケージをビルドします。属性も、コマンド・ラインで指定してやる必要があります。実際に配布されるパッチ・インストーラになります。これをテストするためには、最初にオリジナルのパッケージ(Error/Product.msi)をインストールし、次にパッチを当てます。ファイルが本当に新しいバージョンに変っていることを確認して下さい。開いて、更新プログラムの表示にチェックを入れ、最初にパッチを削除し(変更されたファイルは元のファイルに戻ります)、次にプログラムそのものを削除してください。置かれている管理ソース・イメージを、パッチによって新しいソース・イメージに更新することが出来ます。この新しいソース・イメージは、更新されたフルセットの配布メディアから管理インストールによって作成された場合と同一のソース・イメージになります。Patch.mspプログラムを使用するワークグループのメンバーは、更新を受け取るために、新しい管理ソース・イメージからアプリケーションを再インストールしなければなりません。ファイルをユーザーのコンピュータにキャッシュとして保存するために、ユーザーは以下のコマンドを実行します。断片フラグメント(Fragment)は、大きなインストール・プロジェクトを分割する方法を提供してくれます。ソースのひとかたまりを包み込むラッパーです。中身は、好みに応じて、どんなに簡単でも、どんなに複雑でも構いません。プログラム開発で使用するオブジェクト・ファイルやライブラリと同じように、フラグメントは他の製品のインストーラ・パッケージにリンクして組み込むことが出来ます。ファイル)にコンパイル出来るものです。手法を使うことで、劇的に加速することが出来ます。ファイルを、新しいものも、古いものも、まとめてリンクして、最終的なパッケージを作成します。多少わざとらしいものにならざるを得ません。最初のインストーラを再利用しますが、論点を説明するために、いくつかの部分を切り出して、独立したフラグメントに外部委託します。ユーザー・マニュアルのファイルをインストールするコンポーネントはメインのソースから削除しました。従って、下記の参照は指し示すものが無いものになります。Description='完全パッケージ。Description='取扱説明書。対しては、参照するだけにします。同じものを二つの箇所で宣言することは出来ないからです。フラグメントの中に代理を置くことが出来るものは、すべて変異形のタグを持っています。</Fragment></Wix>私たちは既にこの二つのファイルをコンパイルし、リンクして、一つのインストーラ・パッケージにすることが出来ます。この二つのコンパイルの単位を一緒にリンクするためには、ソースには一行も加える必要が無い、ということに注意して下さい。一つのファイルからもう一つのファイルで定義されているコンポーネントを参照している、という事実さえあれば、期待する通りのリンクが生じます。フラグメントの中にある一つの要素を参照すると、フラグメント全体が開かれて、フラグメント内の全ての要素が直ちにアクセス可能になります。この動作は、いつものプログラミング言語で慣れているものとは異なっています。フラグメントをリンクすると、別の場所で定義されている要素を使うことが出来るようになるだけでなく、参照されているフラグメントの要素を一つでも使うと、常に、全部の要素が有効になるのです。サンプルをビルドするためには、下記のコマンドを使います。Manual.wixobjフラグメントの用途は多岐にわたっていて、単一のセットアップ・プロジェクトの中で使えるだけでなく、異ったプロジェクト間で共通の項目を共有するために使うことも出来ます。提供する機能などを共有している場合)、一つのアプリケーションを削除しても、他のアプリケーションがまだ必要としている共通ファイルは決して削除しないようにする必要があるでしょう。いう場合、共通ファイルをそれ自身の独立したフラグメントに入れて、別々のアプリケーションの全てのセットアップから、そのフラグメントを参照して下さい。この共通ファイルを必要とする全てのアプリケーションを記録しておくことが出来ます。新しいバージョンが決して古いもので上書きされないように、バージョン管理のルールを共通ファイルに対して適切に適用することが出来ます。融合するものフラグメントを使用すると、大きなパッケージを管理可能なソース・コードの固まりに分割することが出来て、開発者の共同作業やコードの再利用が可能になります。ソース・コードが共有可能であり、また、実際に共有されるであろう社内開発に最も適していると言えます。第三者に完全なインストーラ・パッケージを提供することが出来る、もっと強力なもう一つのメカニズムが存在します。マージ・モジュールです。依存しているとしましょう。彼らの製品をインストールするために作られたマージ・モジュールを使えば、彼らの製品をあなたの製品の一部として、同時に二つをインストールすることが出来るようになります。マージ・モジュールを記述する方法は、今までやってきたスタンドアロンのソース・ファイルの場合と非常によく似ています。私たち自身が定義しなければなりません。</Module></Wix>サンプルでは、第二のマージ・モジュールも使います。ソース・ファイルは前のものとほとんど同じですが、次の点で違っています。元のハイフンをアンダースコアで置き換えたものにしなければいけません。ソース・ファイルを書きます。Comments='ほげはぴよソフトの登録商標です。1.0'>通常のコンポーネントの代りにマージ・モジュールを参照します。ファイルを指し示します。ダウンロードすることが出来ます。マージ・モジュールは、個別にビルドする必要があります。Tramontána何よりもコメントと寄稿を歓迎します。softark読みやすくて正確な翻訳を目指しましたが、解釈の誤りと技術的な間違いが含まれていないという保証は出来ません。間違いの指摘や修正案の提示を歓迎します。