Windows Installerに対応したInstallShieldは最終的にWindows Installerのデータベースファイル（msiファイル）を生成するのが目的なので、アプリケーション自体にバグがあっても最後にできあがったmsiファイルが正常なものなら問題はありません。ここでいうInstallShieldのバグのほとんどはInstallShieldが自動的に生成するプロジェクトファイル（テンプレート）のバグや設定の違いによるものです。プロジェクトファイルの設定はInstallShieldアプリケーションをバージョンアップしても引き継がれるものなので、古いバグといえど問題になることがあります。ここでは今までにあったバグやトラブル対処法について取り上げてみることにします。なおここで採り上げるのはすべて「基本msiプロジェクト」に関するもので「標準プロジェクト」に特有な問題は含みません。
製品を「このコンピュータを使用するすべてのユーザ」に対してインストールするか、現在ログオンしているユーザーに対してのみインストールするかを選択するところです。ここはなぜか伝統的にバグの多い箇所です。
Nextボタンではラジオボタンの選択に応じてALLUSERSプロパティに「1」かNULL（何も無いこと）をセットしなければなりません。初期の頃はこれに1をセットするだけでNULLにしていなかったため、一旦次のダイアログに移動してまたCustomerInformationダイアログに戻ってきてラジオボタンを選択しなおしてもALLUSERSプロパティに「1」がセットされたままというひどいバグもありました。
・InstallShield Professional for Windows Installer Edition 2.03の場合
NULLをセットすべきところが「0」となっているため予期せぬ振る舞いを起こすバグがありました。
・InstallShiled Developer 7.0 Service Pack 3の場合
今度は「1」をセットすべきところが「2」になってました。「2」だとユーザーの権限に応じて異なるインストールの仕方をするので間違いとは言えないまでもやはり期待通りの動作をしないことがあるという点で誤りでした。
正しくはこうあるべきです
| イベント | 引数 | 条件 |
|---|---|---|
[ALLUSERS] |
1 |
ApplicationUsers="AllUsers" And Privileged And ProductState <= 0
And VersionNT |
[ALLUSERS] |
{} |
ApplicationUsers="OnlycurrentUser" And Privileged And ProductState
<= 0 And VersionNT |
これはInstallShield Developer 7で見られました。ヘルプによるとISInitAllUsersはALLUSERSプロパティを「2」にセットするそうです。なぜそうする必要があるのか、まったくもって余計なお世話といわざるを得ません。（ISSetAllUsersというInstallShield提供のカスタムアクションもありますがこれとは別物です。）
フォントに関してはsetup.exeとmsiファイルの二つの要因があります。なおこの問題は同じWindows 95でもマシンによって問題なかったり文字化けしてまったく読めないなど様々なようです。以前、梵字（サンスクリット文字）のフォントを入れたらインストーラのフォントが梵字になってしまいまったく読めなくなったことがありました。理由はよく分かりません。（というか面倒なので突き詰めていません。）
まずsetup.exeについてですが、setup.exeは通常のWindowsアプリケーションなので表示はダイアログリソースのフォントの設定に依存します。これがMS Sans Serifのような英語フォントの8ポイントサイズになっていることが原因です。 （要するにInstallShieldのローカライズがちゃんとなされていないということですが... ）
これを直すにはVisual Studioのようなリソースの変更ができるアプリケーションでsetup.exeを開いてダイアログリソースのフォントを修正するか、あるいは同じIDで日本語用のダイアログを追加します。C/C++で開発を行っている人なら大抵やり方を知っていますので分からなければそうした人にやってもらってください。ビルド後にできるsetup.exeをいちいち直していたのでは大変ですので、オリジナルのsetup.exeを直すようにしたほうがいいでしょう。オリジナルはたとえば「C:\Program Files\InstallShield\Developer\Redist\Language Independent\i386」のようなパスにあります。
msiファイルに起因する問題は、表示用にセットされているフォントが「MS Gothic」や「MS UI Gothic」となっていることが原因です。これをWindows 95でも確実に使える「ＭＳ Ｐゴシック」などにすればＯＫです。変更するには「ディレクトエディタ」（または「パワーエディタ」）のパネルに行って「TextStyle」テーブルを選択し、「TextStyle」列の値が「MSGothic9」となっている行の「FaceName」列を変更します。なお使用するマージモジュールの中で同じ「MSGothic9」の項目があるとビルド時に上書きされてしまうので、ビルド後も正しくセットされているかmsiファイルをOrca等で開いて一度確認したほうがいいでしょう。もし上書きされていたらマージモジュールに対して同じ操作をするか、必要なければTextStyleテーブルの行を削除します（多くの場合マージモジュールにTextStyleテーブルは必要ありません）。
「README」の実体は「ARPREADME」というプロパティです。これをプロパティマネージャーで削除すればいいのですが、InstallShield Developer 7以降で「SetARPReadme」というカスタムアクションがシーケンスに自動的に挿入されているとそれだけでは効きません。「SetARPReadme」というカスタムアクションも一緒に除いてください。
そもそも「SetARPReadme」が何のためにあるかというと「README」にこれからインストールするマニュアルなどのファイルパスを入れたいといった場合、そのパスを予め入れておくわけにいきません。パスはインストール時に決まるからです。といって単純に「README」にプロパティ名を[ ]で囲って入れてもそのままではパスに置き換わりません。そのプロパティ名→値の変換を行うのが「SetARPReadme」の役目です。
InstallShieldに付属のマージモジュールを使用すると検証時に
Reg key Global_Controls_XXX is used in an unsupported way
といった警告がたくさん表示されることがあります。これはマージモジュールに問題があるのですがおそらく実害はないと思われます。つまりWindows Installerではレジストリにデータを書き込む場合、一般的にはRegistryテーブルを使用するのですが、COMやタイプライブラリの登録には専用のClassテーブルやTypeLibテーブルなどを使うことになっています。結果的にレジストリに書き込まれることは同じなのですがWindows Installerのガイドラインでは専用のテーブルがある場合はそちらを使うことになっています。Classテーブル等を使わなかった場合、アドバタイズインストールの際にCOMインターフェイスがアドバタイズされないことになります。これは理由があってあえてそのようにしているのか今のところ不明です。もし気持ちが悪いようなら作り直してもいいでしょう。（あえて推奨はしませんが。）
一旦ファイルの拡張子をDLLにして登録情報を抽出します。その後「ディレクトエディタ」（または「パワーエディタ」）で「File」テーブルの該当する行の「FileName」列と「ISBuildSourcePath」列を修正して拡張子を戻します。「File」列にあるキーは「.DLL」が付いていても問題ありません。（気になるなら直してもよいですが）
「ディレクトエディタ」（または「パワーエディタ」）で「Shortcut」テーブルの「IconIndex」列のところ見るとなぜか「0」であるべきところに「1」が入っていることがあります。「0」に直すと大抵直ります。
検証を行って初めて分かることですが「Control」テーブルの「Attributes」フラグにWindows Installerでサポートされないビットが立ってしまい、検証時に警告がでることがあります。これも「ディレクトエディタ」（または「パワーエディタ」）で「Control」テーブルの「Attributes」列を直接修正します。
（これを修正するスクリプトを作成しました（2005年2月） ）。
・Iconの場合
「5767169」となっていたら「5242881」に直す。
・Bitmapの場合
「262145」あるいは「1310721」となっていたら「1」に直す。
プロジェクトファイル（.ismファイル）に「ポ」が含まれているとプロジェクト一覧に表示されないというバグがありました。この場合ファイル名を変えてください。（根本的な解決になっていませんが...）
これは昔からのバグというかInstallShieldの仕様なのかもしれませんが、Type 19のカスタムアクション（エラーメッセージを表示してインストールを終了するためのカスタムアクション）がカスタムアクションビューで作成することができません。そのため「ディレクトエディタ」（または「パワーエディタ」）で作成するしかないのですが、ここで作成してカスタムアクションビューに戻ると左側のパネルの表示が直前に表示したカスタムアクションのプロパティのままになっていて更新されません。知らない人がこれを見るとおそらく混乱します。
Type 19のカスタムアクションを通常の方法で作成できないため、もしかしたらその存在を知らずに苦労している人がいるかもしれません。(2004/3/9現在、DevStudio 9でも改善されていない
。InstallShield 12では直っている。）
DevStudio 9になって「システム検索」のビューで「既定の検索の追加」という機能が付きました。この中には「Adobe Acrobat Reader 5のインストール場所」とか「Internet Explorer 5」といった項目に混じって「MDAC Version 2.6」と「MDAC Version 2.7」という項目があります。これは何をしているかというと、まずレジストリパスHKLM\Software\Microsoft\DataAccessにある「FullInstallVer」というレジストリ値（この中にMDACのバージョンが文字列で入っている）を「MDACFOUND」というプロパティに代入し、インストーラのインストール条件のところで、「MDACFOUND>="2.62.7400.1"」といった条件が満たされていなければインストールを中断するというものです。この条件式がおかしいことは明らかです。「MDACFOUND」プロパティにはレジストリから取得した"2.81.1117.0"といった文字列が入るのですが、単純に文字列として比較しているため、もしMDACFOUNDの値が"2.100.0.0"であったならば、（100は62よりも大きいにもかかわらず）システム上のMDACのバージョンの方が古いと判断されてしまいます。このひどいバグがInstallShield 12でも直っていないのは信じられないくらいです。
ちなみに上記の設定に関するテーブルは「AppSearch」、「RegLocator」、および、「LaunchCondition」です。これらはダイレクトエディタで確認することができます。
PatchWelcomeダイアログのNextボタンなどいくつかのコントロールのBase Text Styleが<デフォルト>のままになっており、MSGothic9になっていない。パッチを作成した場合、環境によってはもしかしたら文字化けするかも。
InstallShield Developer 7まではマイナーアップグレード（インストーラのバージョンだけを変更して製品コードを変更しないアップグレード）かどうかの判断を行わず、旧バージョンがすでにインストールされているときにsetup.exeを普通にダブルクリックすると「別のバージョンの製品が既にインストールされています。このバージョンのインストールを続行できません．．．」と表示されていた。
ちなみにこのようなときはコマンドプロンプトから
msiexec /i [path to .msi file] REINSTALL=ALL REINSTALLMODE=vomus
と打ち込めばマイナーアップグレードを行うことができる。(But who wants to do that?)
DevStudio 9から「ファイル」メニューの「名前を付けて保存」を行うと製品コード（と製品名も）が勝手に変わってしまうようになった。パッケージコードを変えるなら分かるがなぜ製品コードを勝手に変えるのか。気が付きにくいのでトラブルの元だし、余計なお世話である。よく見ると保存ダイアログボックスの下に「新しいプロジェクトGUIDを作成し、保存されたプロジェクトに割り当てます」というチェックボックスが付いている。「プロジェクトGUID」とは何のことかと思ったら製品コード（GUID)を意味するようである。このチェックボックスを外せば今まで通り単純なコピーの保存になるようだ。しかしながら 、変えるならパッケージコードも変えるべきだし初期設定でオフになっていないと混乱の元だ。
InstallShield Developer 7のレジストリビューがWindows XP SP2から正常に表示されなくなったようだ。もともとDeveloper 7はXPを対応動作環境として謳っていないのでクレームを付ける訳にもいかない。DevStudio 9では問題なし。Developer 8は未確認。
ダイアログにスクロール可能テキストオブジェクト（LicenseAgreementダイアログで使用許諾契約書を表示するのに使われている）を配置し、その「File Name」プロパティでリッチテキストファイルを指定してもビルド時にエラーになったりInstallShieldがクラッシュすることがある。ディレクトエディタでみると「Control」テーブルのそのScrollableTextの行のISBuildSourcePath列にパスが入 っていないことがある。この場合手動で入れれば直る場合がある。これでも直らない場合「ISLocalControl」テーブルをチェックする。たとえばLicenseAgreementダイアログの使用許諾契約書を、日本語環境では日本語、英語環境では英語のものを表示したいとする。２種類のRTF(Rich Text Format)のファイルを用意し、LicenseAgreementダイアログのMemoコントロールの「File Name」属性に対し、英語と日本語のダイアログでそれぞれの言語のファイルパスを指定するわけだが、この二つのパスは「ISLocalControl」テーブルに保存される。テーブルはたとえば以下のように２行にならなければならない。
| Dialog_ | Control_ | ISLanguage_ | Attributes_ | X | Y | Width | Height | Binary | ISBuildSourcePath |
|---|---|---|---|---|---|---|---|---|---|
LicenseAgreement |
Memo |
1033 |
7 |
7 |
53 |
358 |
130 |
|
Path to English RTF |
LicenseAgreement |
Memo |
1041 |
7 |
7 |
53 |
358 |
130 |
|
Path to Japanese RTF |
ところがなぜか１行分のデータしか作られないことがあるので、手動で行を追加すると大抵直る。
Control Eventの順番は「ControlEvent」テーブルの「Ordering」列の値で決まる。同一コントロールに対してこの値は本来重複してはならないのだが同じ値が入っていると順番の変更がうまくいかないことになる。この問題はDevStudio 9ではControl Eventを表示したときに自動的に修復されるようだ。（プロジェクトを何も修正した覚えがないのにプロジェクトを閉じようとしたときに保存するかどうか尋ねられることがあるのはこのためと思われる。） （→これを修正するスクリプト ）
※InstallShieldに付属するマージモジュールにもバグがないとは言えません。たとえばかつてマージモジュールのこんな箇所をみかけました。VBScript（Windows InstallerはVBScriptで書かれたのカスタムアクションを実行する機能があります）でバージョンを比較するところですが、それを文字列として比較していたのです。Windowsでのバージョンは“1.03.0004.33”のようにピリオドで分かれた最大４つの数字のブロックからなるのですが、0が意味を持たないのは明らかです。つまり“1.03.2”と“1.3.2”は同じものです。文字列として単純に比較していては結果がおかしくなるのは明らかです。
他にもInstallShield社が作成したマージモジュールには色々バグが多く、マージモジュールの作り方が分かってないのではと疑いたくなります。
一方、Microsoft純正のマージモジュールならバグは無いかというとそうでもないようです。MSDE 2000のマージモジュールなど結構バグがあったりします。もっともあれだけ巨大なマージモジュールになると１つ２つのバグがあっても不思議はないですが。
一般情報→概要情報ストリームの各項目で全角文字を使用すると、ビルドしてできた.msiファイルのプロパティから「概要」を見ると全角文字が入っていたところが正常に表示されない。テクニカルサポートも認めたバグであるが、結局InstallShield 12では修正されなかったようである。
ページの先頭へ戻る