WiX Toolset – Bootstrapper

WiXは少しお休みして、現代史の勉強をしようと思っていたのですが、Bootstrapper Projectを習得したいという欲求の方が強く、結局WiXの勉強を継続しました。

完璧ではないのですが、概要は理解したのでご報告します。

Bootstrapper というのは、インストール・プロジェクトの途中で、別のインストールプログラムをインストールしようというものです。

現在、Visual StudioではWixをベースにしたBootstrapper Projectをサポートしています。私もこのBootstrapper Projectを使いました。

さて、今Accessを必要とするアプリケーション・プログラムがあるとします。
すなわち、このプログラムが動作するためには、ターゲットコンピュータに予めAccessがインストールされていなければいけません。

もし、ターゲットコンピュータにAccessがインストールされていなければ、所定の場所(WEB)から無料のAccessRuntimeをダウンロードして、ターゲットコンピュータにインストールします。

今、アプリケーションのインストールプログラム(MyAppli.ms)は完成しているとして、ここでやるべきことは、
1. ターゲットコンピュータに必要なAccessがインストールされているかどうか調べ
2. なければAccessruntimeをダウンロードし、インストールする
3. Accessruntimeのインストールが成功する、あるいはもともとAccessがインストールされていれば、
4. 自分のアプリケーションをインストールする。
というものです。

Visual Studioを起動して、
プロジェクト・テンプレートのWindows Installer XMLからBootstrapper Projectを選択します。
その中心部分(といっても僅かですが)は以下のようなものです。

	<Bundle Name="Bootstrapper1" Version="1.0.0.0" Manufacturer="" UpgradeCode="98647ef2-65fe-4702-8b60-f59824fb2642">
		<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />

		<Chain>
			<!-- TODO: Define the list of chained packages. -->
			<!-- <MsiPackage SourceFile="pathtoyour.msi" /> -->
		</Chain>
	</Bundle>

この<Chain>要素にExeあるいはMsi形式のセットアッププログラムを記述します。
書かれた順番にインストールが実行されます。

AccessRuntimeExe形式なのでExePackage 要素を使って、またMyAppliMsi形式なのでMsiPackage 要素を使って、以下のように書きます。

	
      <ExePackage Id="AccessRuntime2013"
                  DownloadUrl="http://www.aa.bb.cc/XXX/AccessRuntime_x86_ja-jp.exe"
                  SourceFile="AccessRuntime_x86_ja-jp.exe"
                  Compressed="no" Permanent="yes"
                  InstallCondition="NOT VersionNT64"
                  DetectCondition="NOT VersionNT64 AND (LocalServer3214 OR LocalServer3215)" />

      <RollbackBoundary />

      <MsiPackage SourceFile="MyAppli.msi" DisplayInternalUI="yes"
                  Permanent="yes" Visible="yes"/>

ここでMyAppli.msiのインストールはあまり問題がないと思います。

実は、WiXのBootstrapper Projectには問題があって、Chain要素に書かれたプログラムをインストールするだけでなく、自分自身もターゲットコンピュータにインストールするのです。

すなわち、上の例でいえばBootstrapper1もインストールされて、Windowsの「プログラムと機能」画面に、Bootstrapper1プログラムも表示されます。

そして悪いことに、Bootstrapper1をアンインストールすると、上の例で、AccessRuntimeMyAppliもアンインストールされてしまいます。

これを避けるため、ExePackage 要素とMsiPackage 要素の属性で、Permanent=”yes” を宣言しておきます。

これによって、Bootstrapper1をアンインストールしても、Chain要素のプログラムがアンインストールされることはありません(の筈です)。

WiX4では修正されるようですが、期待しています。

また、<RollbackBoundary />はこれに続くインストールで、不具合が起こってもそれ以前の部分は、Rollbackしないことを指示しています。

すなわち、MyAppliでインストールが中断されても、AccessRuntimeのRollbackはしない指示です。

 

さて少し厄介なのは、Accessがターゲットコンピュータにすでにインストールされているかどうかを調べる部分です。

WiXでは、ターゲットコンピュータのレジストリを調べる機能が用意されています。

Microsoft Officeには、ProgIDが付けられています。

例えば、Accessであれば、Access.Application.14のようです。ProgIDは製品版でもRuntimeでも同じです。

Access2010のProgIDAccess.Application.14、Access2013のProgIDAccess.Application.15です。

またOffice製品は、CLSIDもつけられていて、このCLSIDからターゲットコンピュータのどこにAccessがインストールされているを知ることができます。

以下にサンプルを示します。(後日記:以下の部分を<BootstrapperApplicationRef>要素の直後に挿入します。多分)

    <util:RegistrySearch
      Variable="varClsId3214"
      Root="HKLM"
      Key="SOFTWAREClassesAccess.Application.14CLSID"
      Result="value"/>
    <util:RegistrySearch
      Variable="LocalServer3214"
      Root="HKLM"
      Key="SOFTWAREClassesCLSID[varClsId3214]LocalServer32"
      Result="exists"/>

最初のRegistrySearchAccess.Application.14CLSIDの値を求め、この値を変数varClsId3214にセットし、次のRegistrySearchで、varClsId3214をキーとして、LocalServer32(当該ソフトのインストール先)の存在を確認します。

LocalServer3214の値が”1″ならAccessがインストールされているし、”0″ならインストールされていません。

この値は変数LocalServer3214にセットされます。

したがって、LocalServer3214が”1″なら、Accessインストールを飛ばしてMyAppliをインストールし、”0″ならAccessがインストールされていないので、
ExePackage 要素のDownloadUrl要素に示されたURLから、AccessRuntime_x86_ja-jp.exeをダウンロードし、ターゲットコンピュータにインストールしてから、MyAppliのインストールをします。

以上、WiXについて私が当初目標にしていたところまで勉強を進めました。
WiXで唯一残念なのは、上で書いたようにBootstrapper Projekutで自分自身をインストールすることですが、多分これは次のバージョンV4で修正してくれると思います。

それも間もなくリリースしてくれそうなので、期待しています。

最後に一つだけ追加します。

自分が開発したプログラムの依存ライブラリーも、ターゲットコンピュータにコピーしなければいけませんが、これはVSの参照設定を見ればいいと思っていました。

一方、VS2010では簡単なセットアップ・プロジェクト構築ができますが、ここには依存ライブラリーを収集する機能があります。

ところが、VSの参照ライブラリーとVS2010の依存ライブラリーが少し違います。
どちらがいいのか分かりませんが、VS2010のセットアップ・プロジェクトなら間違いないかなと思っています。

さて、WiXでのセットアッププログラムの作成をご紹介してきました。
一通り勉強してみて、WiXで大抵のことはできる、InstallShieldInstallAwareを使う必要はないと確信しました。

ただし、以前ご紹介した参考書は役に立ちましたが、特にBootstrapの記述が十分ではないし、他にもドキュメントが少ないので、完璧に理解したというわけにはいきません。

とはいえ、WiXは私自身長年習得したいと思っていた技術でしたので、今回一通り勉強できて、また「使える」という感想を持つことができて、ほっとしています。

細かいことは書かないで来ました。
細かいところまで解説する知識がないし、エネルギーがなかったからですが、もう少し勉強して、自信が持てて、更に気分が向いたら、別の場所でWiXの解説をしたいと思います。

error: コピーできません !!