Lesson 1 始めよう

既に前書きで述べたように、WiX ツールセットは XML ソース・ファイルを使用して、 アプリケーションのインストール・プロセスを構成するコンポーネントを記述します。 また、XML ソース・ファイルには、ショートカット、レジストリおよび .ini ファイルの変更、 サービスなど関する付加的なデータも記述します。 さらに、インストーラ・パッケージは、ユーザーのディスクにコピーしたいファイルに加えて、 インストールのプロセスに参加はするけれども実際にはインストールされないヘルパー・ファイルを持つことが有り得ます。 そういうヘルパー・ファイルとしては、インストールの UI に使用されるダイアログやアイコンおよびビットマップ、 あるいは、ライセンス・ファイルや readme ファイル、さらには、Windows Installer がサポートしていないプログラム的な処理を実行するカスタム DLL が含まれます。 (例えば、何らかのユーザー登録やキー・チェック・ロジックを実装したいと思うかも知れませんが、 Windows Installer はそういう処理をサポートしていません。)

これら全てのものをソース・ファイルに記述して、WiX のコンパイラに供給します。 ツールセットはいくつかの部分から構成されていますが、そのうちの二つを使って、インストーラ・パッケージをコンパイルします。 ここで Sample.wxs というソース・ファイルを用意したと仮定しましょう。 最初に、

candle.exe Sample.wxs

というコマンドで、コンパイルの第一段階を実行して、Sample.wixobj という半分消化されたファイルを作成します。 このファイルはまだ XML ですが、その内部構造は人間が読むことを想定したものではありません。 通常のコンパイラ用語でオブジェクト・ファイルと呼ばれるものだと考えて下さい。 次に、第二のコマンドとして、

light.exe Sample.wixobj

を実行し、この中間表現を最終的なパッケージである Sample.msi というファイルに変換します。 コンパイラとリンカにそっくりですね。実際は、それだけに留まりません。 リンカは、明示的にそうするなと指示しない限りは、検証ステップを実行して、 完成されたインストーラ・データベースを数百項目にわたってチェックし、エラーや問題が無いかを調べます。

今日のコンパイラでは普通のことですが、もはやコマンド・ラインでの使用に限定されてはいません。 Microsoft Visual StudioSharpDevelop のような統合開発環境も、IDE そのものの内蔵機能やアドインとして、 WiX プロジェクトをサポートすることが出来ます。 Visual Studio の場合は、WiX v3 パッケージをインストールすると Visual Studio の WiX サポートが自動的にインストールされます。 この手法を使って、独立したセットアップ・ソリューションを作成することも出来ますし、 セットアップを部分プロジェクトとして全体のソリューションに含めることも出来ます。 この場合、最終的なセットアップ・パッケージをビルドするためにプログラミング環境を離れる必要はなくなります。

コンパイラとリンカの比喩は非常に明解で、WiX が実際のインストール・パッケージをビルドする方法を理解するのに役立つかも知れません。 しかし、もうすぐ書き始めようとしている WiX のソースをスクリプトやプログラミング言語のようなものだと考えるべきではありません。 私たちがソースに記述するのは、アプリケーションをインストールするのに必要なステップ操作を集めたものではありません。 アプリケーションの配布に使用する .msi ファイルは、セットアップ・アプリケーションではなく、インストール・データベースです。 プログラムのロジック、すなわち、アプリケーションをインストールする方法や、レジストリ・キーを修正する方法、 ショートカットやユーザーやネットワーク共有を作成する方法、ウェブ・ディレクトリやサービスを操作する方法は、すべて、 Windows Installer の方に内在しています。 私たちが作成するセットアップ・ファイルは、Windows Installer によって何が実行されるべきかを記述し、 そして、配置すべきファイル(およびインストールのプロセスで使用するインタフェイス要素)を提供するだけのものです。

データベースの手法を取っているということは、WiX のソース・ファイルは通常のプログラムと同じようにビルドされる訳ではない、 ということを意味しています。 WiX には順次実行という概念はありません。 最初のソース行が次のソース行に先行して実行されるという想定はありません。 参照に先立って宣言が必要であるということもありません。 さまざまな要素が別の場所で記述されることが有り得ます。 そして、要素間にリンクが必要な場合は、私たちが提供する一意の識別子を使用して、一方から他方を参照しなければなりません。 プログラミング言語の用語で考える必要がある、というのであれば、WiX は命令的・指示的な言語ではなく、関数的・宣言的な言語であると考えて下さい。

また、WiX はそれ自体としてはインストール環境ではない、ということにも留意して下さい。 簡単に言うと、WiX は、インストールの要求事項を記述するための使いやすい XML スタイルの方法であり、 その記述をコンパイラとリンカによって Windows Installer の .msi データベースに変換するものである、ということです。 この面において、WiX は Windows Installer のテクノロジを包んだ比較的薄いラッパーです。 WiX がセットアップ開発者を支援する付加的な機能をいくつか提供しているのは事実ですが、 WiX の能力は基礎となっているテクノロジによって決定されており、その制約も WiX 自身のものではなく Windows Installer 自体が持っている制約なのです。

↑ 先頭  |  • 目次  |  « 前へ  |  次へ »  |  ∗ 原文

Table of Contents

1 始めよう

  1. ソフトウェア・パッケージ
  2. 中に入るファイル
  3. 使用に供する
  4. 便利な追加機能
  5. どこにインストールするか
  6. 条件付きインストール
  7. ファイルだけでなく
  8. 削除時の孤児化

2 ユーザー・インタフェイス

  1. 最初のステップ
  2. カスタムの設定
  3. UI の魔法
  4. 英語はわかりますか
  5. チェーンの新しい環
  6. 地域化を考える

3 イベントとアクション

  1. 列に並んで
  2. 追加のアクション
  3. 本に書かれていないこと
  4. コントロールをコントロールせよ
  5. マネージする方法
  6. 後の段階で

4 アップグレードとモジュラー化

  1. 古いのを探す
  2. 自分自身を置き換える
  3. パッチワーク
  4. 断片
  5. 融合するもの

5 Net と .NET

  1. .NET の枠組み
  2. ブートストラップ
  3. インターネットを起動する
  4. ウェブ・ディレクトリ
  5. サービスの提供

6 COM、式の構文、その他

  1. 違う色のコンポーネント
  2. 式の構文
  3. 書式指定文字列
  4. DDE 接続
  5. ディレクトリの作成
  6. 複数メディアのインストーラ
  7. プログラムの追加と削除の項目
  8. 新顔のユーザー
  9. 環境に優しく
  10. XML
  11. COM+ アプリケーション
  12. バージョンごとに

7 SQL

  1. データベースを作成する

8 ユーザー・インタフェイス再び

  1. 一つだけのダイアログ
  2. チューニング・アップ
  3. 相互作用
  4. カスタマイズがいっぱい
  5. これが進捗ですか
  6. よく出来ました
  7. 法律用語
  8. 順番外
  9. 英語はわかりませんか

9 トランスフォーム

  1. インストーラを変形する

10 標準ライブラリ

  1. カスタム・アクションとユーザー・インタフェイス
  2. お静かに願います