インストーラー開発メモ

●インストーラーとセットアップって概念を分割した方が良い。
インストール時とその後も環境設定等ができるので。

「inst_setup.jpg」をダウンロード

インストーラー開発者が全部請け負うとそれぞれ品質確保が難しいのでソフトウェア本体開発者と連携して作った方が結果的に良い。
ソフトを一人で作ってる場合は・・・頑張ってくれ(笑)
ただ、分けた方がメンテの面でもそれぞれ記録するログファイルを分けるなどやりやすくなりまっせ。

●なぜマルチバージョンで動作しないのか?を考える

インストーラーと一見話が逸れるかと思われるかもしれないが、重要な話なので、追記しておきます。
お客様よりマルチバージョンで使いたいという要望を頂きます。
最終的に火の粉を浴びるのがインストーラー開発担当だったりしますが、それはさておき、そもそもなぜマルチバージョン同居ができない製品なのか?
というユーザー側の視点が抜けている点も見逃せない。
これは使用(を検討)する製品がどういう仕組みかをあらかじめ考慮し、システムを構築するうえで重要な話なのですよ。

マルチバージョン同居ができない理由というのは簡単に言うと、製品動作のために必要な情報が固定場所で管理されているから・・・なのです。

例えばあるDLLを動的ロードし、実行するような仕組みを持った製品があるとします。
動作するプログラムはロードしたいDLLをどこから見つけるのか。

OSには環境変数(または今回の事例の場合システム環境変数と言ってよい)があります。
多くはPATHという変数で定義されています。

これは(主には)ロードしたいAPI(Windowsの場合はDLL)の場所を;(セミコロン)区切りで列挙したもので、定義されたフォルダ名を順番に探します。

マルチバージョン同居が出来ない製品の場合、このシステム環境変数PATHに依存した作りでプログラムを作成してるケースが多いです。

製品に含まれるDLLを製品の実行形式(.EXE)が読み込む仕様だったとする
その場合マルチバージョンをインストーラーが許したとしても・・・

バージョン1.0なら自身のインストール先\LIB
を参照。

バージョン2.0なら自身のインストール先\LIBを参照・・・したいのだが、先にPATHに設定されているのがバージョン1.0のインストール先だったとする。
で、ロードしたいAPI名が同じだった場合、当然そのままバージョン1.0のを読み込む。
APIに互換性があればそれも問題が無いが、たいていAPIが拡張されていたりで、そのままだと不整合を起こしてエラーが発生する。
(DLL地獄とか呼ばれる要因もこれ。本来ならAPIは下位互換を保たなければならないのだが・・・)

マルチバージョンインストールができない犯人にインストーラーが挙げられる事があるのだが、それは間違っている。
インストーラーは製品が動作できない環境を単純に回避しているにすぎない。

で、上記の問題をインストーラーで吸収できかというとそんな事はない。
プログラムの構造そのものを根本的に見直さないといけない。
(上記の他、TCP/IPのポート番号を使用するサービス名の重複、固定されたレジストリー情報等、ソフトウェア本体に潜む要因は沢山存在する)

最近はアプリケーションの仮想化が具体的になっている。
まずはそちらの導入を検討する等をおすすめしたい。それですべての製品が解決するわけではないが、検討の余地はあると思う。
あるいは環境を分けても良いというのであれば、仮想化のOS上で別バージョンの製品を運用するという使い方もある。

既に出荷された製品に対して、マルチバージョンインストール可能にしろというのはかなり無理があるのだ。


●InstallShieldのやっちまった!メモ

・レジストリー登録はスクリプトでやるべし。サブキー階層はなるべく細分化して登録すべし。
会社名やブランド名と組織内製品で共通して使用するサブキー作成時はインストールログを無効にして作成すべし。

やらないと・・・
Reg


・複数インストーラーをサイレントで呼び出すラッパープログラムを作成。
製品A、B、Cの順でインストーラーを呼び出す。
その間、Bのインストール後、セットアッププログラムを実行したが、
プログラムが見つからない。
InstallShieldとそれ以外で作成したプログラムの完全な同期は不可能と判明。
上記の例はBのファイルコピーが完全に終わっていなかった。


・InstallShieldのサイレントアンインストール時はOS再起動させるべし。
ローカルディスクのsetup.exe(通常%programfiles%InstallShield Installation Information\{製品毎に設定されているGUID})配下に格納されている。GUIでのアンインストールはその場で削除してくれるが、サイレントは再起動後削除するようレジストリーに登録される。

この状態で同じ製品をインストールすると、OS再起動のタイミングでsetup.exeが削除される。
コントロールパネル->プログラムと機能から呼び出されるのはこのsetup.exeなので、製品はアンインストールされています云々と表示されて、アンインストールできなくなる。

ちなみに
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet(環境により001だったり・・・)\Control\Session Manager
値名
PendingFileRenameOperations
にOS再起動時、改名、削除されるファイル一覧が登録されている。

・外部プログラムが動かない!
InstallShieldスクリプトで実現困難な処理はC++等でDLLやコマンドを作成して呼び出す。
でもruntimeを必要とするビルドをしちゃうとインストール時、まだOSがピュアな状態だと動かないので注意。
runtimeを含めたモジュールにするか(こっちがお勧めかな・・・)、インストール処理冒頭でruntimeをインストールする。

注意事項!(必読)
本ページは私Hide@Yozakuraが10年近く携わっている(現在も継続中)インストーラー開発に関するアレコレ経験談を独自調査結果や愚痴を交えながらお伝えするページです。

あくまで本サイトに記載する内容に関する情報は経験談にすぎず、過度な信用は危険です。
本サイトに記載する内容を把握された上で、なおかつご覧になられた方が再度検証したうえで結論を出されることを強く希望します。

また、本サイトに記載する内容をご自身の業務に利用した場合、いかなるトラブルが発生した場合でも本サイト管理人であるHide@Yozakuraは責任を負えない事をあらかじめ申し上げます。
あらかじめご了承ください。

その外メモ

マルチプラットフォームインストーラー開発ツール
InstallAnywhere

アプリケーション仮想化対応デプロイメントツール
AdminStudio

上記Flexera Software 社製

同じ製品を複数インストールしたい場合等もあるが、競合して構築できない場合は以下のような考え方もあり。
(共通で使用するソフトウェア共存問題に対する対処例)
アプリケーション仮想化
VMware ThinApp

ファイル配置に関する規約(?)まだ浸透してないみたいだけど・・・
IBM SDDへの取り組み
http://www.ibm.com/developerworks/jp/autonomic/library/ac-artifacts/



コメント

コメントを書く



(ウェブ上には掲載しません)