- PR -

同一のwidows端末上にmsiパッケージを複数インストール

1
投稿者投稿内容
ゼスパ
会議室デビュー日: 2006/05/24
投稿数: 3
投稿日時: 2006-05-24 01:50
はじめて書き込み致します。

現在、visual studio 2005 のセットアッププロジェクトを利用して
インストーラの作成を行っています。

同一のwidows端末上にmsiパッケージを複数インストールすることが可能かどうか
調査しております。
msi作成時に[ProductCode]が一意に設定されるため、
インストーラ起動時に動的にこのプロパティを再設定できる仕組みがあれば…
と思ったのですが実装方法がわかりません。

ご存知の方がいらっしゃいましたらご教示いただけないでしょうか。
よろしくお願いいたします。

渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-05-24 09:35
引用:

同一のwidows端末上にmsiパッケージを複数インストールすることが可能かどうか
調査しております。


可能だとは思いますが、インストーラによっては実行の結果、システムをリブートさせるものもあるのでなかなか制御が大変だと思います。

引用:

msi作成時に[ProductCode]が一意に設定されるため、
インストーラ起動時に動的にこのプロパティを再設定できる仕組みがあれば…
と思ったのですが実装方法がわかりません。


どうしてそんなことをする必要があるんでしょうか？
「複数の msi」の間に、何か特別な関係でもあるのでしょうか？
とっちゃん
大ベテラン
会議室デビュー日: 2005/07/19
投稿数: 203
投稿日時: 2006-05-24 11:29
引用:

ゼスパさんの書き込み (2006-05-24 01:50) より:

同一のwidows端末上にmsiパッケージを複数インストールすることが可能かどうか
調査しております。

同じパッケージ(ProductCodeの同じもの)を複数というのは出来ません。必ず一つだけになります。

引用:

msi作成時に[ProductCode]が一意に設定されるため、
インストーラ起動時に動的にこのプロパティを再設定できる仕組みがあれば…
と思ったのですが実装方法がわかりません。

ProductCode の値は、ビルド後に変更してはいけません。

ProductCode は日本語では製品コードとも呼ばれる非常に重要な値です。
要するに、Windowsが製品としてのmsiを識別するためのユニーク識別子となるわけですので
おいそれと勝手に変えてしまうわけには行きません。

お使いのインストーラ作成ツールのヘルプに「絶対」に出ていますので、よくお読みください。



なんとなく思っただけなのではずしてるかもしれませんが、
ソリューションごとに msi を作っているということではありませんか？

もし、そうならmsiは配布する製品全体で一つのものにすればOKです。
プライマリのアプリケーションのソリューションに統一してもいいですし、
専用にソリューションを作ってもいいでしょう(VSセットアップであれば)。

_________________
// とっちゃん(高萩 俊行)＠わんくま同盟
// とっちゃん’Blog
// MS-MVP for Developer Tools - Visual C++
// WindowsInstallerの話題はhttp://www.freeml.com/msiまで
ゼスパ
会議室デビュー日: 2006/05/24
投稿数: 3
投稿日時: 2006-05-25 01:18
ひどりさん
とっちゃんさん

ご回答ありがとうございます。

まず背景として、
アプリケーションのバージョンアップに伴い
installshieldからvsへインストーラの
移行を担当することになりました。

このアプリケーションは
ネットワークを介して他の端末のフォルダを監視・処理する機能を持っています。
1つのアプリケーションに対し1つの端末を監視しているため
複数の端末を監視するために、複数インストールする必要があります。

msiパッケージは一度インストールした状態で
再度、インストールしようとするとアプリの"修復"か"削除"を選択する
ダイアログが表示されます。
このダイアログを表示させずに、2つ目、3つ目とインストールが
できればと考えています。
また仮に複数インストールできたとしても
[productcode]単位でインストール状態を判別していそうなので
どれか一つをアンインストールしたら全て削除されてしまうことを危惧して
インストール毎にproductcodeを変更する必要があるのかな？
と思った次第です。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-05-25 02:23
引用:

このアプリケーションは
ネットワークを介して他の端末のフォルダを監視・処理する機能を持っています。
1つのアプリケーションに対し1つの端末を監視しているため
複数の端末を監視するために、複数インストールする必要があります。

msiパッケージは一度インストールした状態で
再度、インストールしようとするとアプリの"修復"か"削除"を選択する
ダイアログが表示されます。
このダイアログを表示させずに、2つ目、3つ目とインストールが
できればと考えています。
また仮に複数インストールできたとしても
[productcode]単位でインストール状態を判別していそうなので
どれか一つをアンインストールしたら全て削除されてしまうことを危惧して
インストール毎にproductcodeを変更する必要があるのかな？
と思った次第です。


インストーラで吸収するような要件じゃないと思うなぁ。
とっちゃん
大ベテラン
会議室デビュー日: 2005/07/19
投稿数: 203
投稿日時: 2006-05-25 11:39
引用:

このアプリケーションは
ネットワークを介して他の端末のフォルダを監視・処理する機能を持っています。
1つのアプリケーションに対し1つの端末を監視しているため
複数の端末を監視するために、複数インストールする必要があります。

どうやってインストール単位ごとに分けているのでしょうか？

少なくとも管理対象ごとにユニークなエントリー情報をもてない限り
複数インストールしても単にカウントがあがるだけで、対象を増やせるようには
ならないと思うのですが？

引用:

msiパッケージは一度インストールした状態で
再度、インストールしようとするとアプリの"修復"か"削除"を選択する
ダイアログが表示されます。
このダイアログを表示させずに、2つ目、3つ目とインストールが
できればと考えています。

この動きは WindowsInstaller アーキテクチャを使っていない場合でもきちんと
ロゴに準拠できるように作られたインストーラなら全て同様の動きをします。
実際うちで以前作っていた独自インストーラも同じように動いてましたよ。


さて、私が思うに InstallShield 時代はスクリプトの中でUIからのフィードバックを
受けて独自にデータを作っていたのではないかと思われます(エントリー情報は
ユニーク名を与えるINIかなにかで実現していたのでしょう)。

昔の InstallShield には同じインストーラでも複数回インストールできてしまう
というバグがありましたので、そのバグを利用して実現できていたテクニックではないかと
思われます。

でこの動きを WindowsInstaller でトレースできるかというと、出来ません。

なので、別途設定ツールを作って以前のインストーラがスクリプトレベルで処理していた部分を
そのツールで吸収するというのが一番無難な解決策ではないかと思います。

ちなみに、インストールしていないけど、任意のファイルを消せるという仕組みは
インストーラに用意されていますよ。

詳しいことは、WindowsInstaller SDK のドキュメント(英語ですけどね(^^をご参照ください。

_________________
// とっちゃん(高萩 俊行)＠わんくま同盟
// とっちゃん’Blog
// MS-MVP for Developer Tools - Visual C++
// WindowsInstallerの話題はhttp://www.freeml.com/msiまで
ゼスパ
会議室デビュー日: 2006/05/24
投稿数: 3
投稿日時: 2006-05-28 00:54
ご回答ありがとうございます。

引用:


どうやってインストール単位ごとに分けているのでしょうか？

少なくとも管理対象ごとにユニークなエントリー情報をもてない限り
複数インストールしても単にカウントがあがるだけで、対象を増やせるようには
ならないと思うのですが？



インストール後の初期設定で
レジストリ登録して一意になるように設定しています。

引用:


昔の InstallShield には同じインストーラでも複数回インストールできてしまう
というバグがありましたので、そのバグを利用して実現できていたテクニックではないかと
思われます。



以前はInstallsheild5.5を使用していました。
上司に確認してみると、とっちゃんさんの仰るとおり
恐らくそのバグを利用して作成しているとのことです。
(既に作った人がいないので詳しいことはわからないそうです)

引用:


インストーラで吸収するような要件じゃないと思うなぁ。



引用:


別途設定ツールを作って以前のインストーラがスクリプトレベルで処理し
ていた部分をそのツールで吸収するというのが一番無難な解決策ではないかと思います。



上司に相談したところ、お二人の仰るように
別途設定ツールを作成する方向で決定しました。

迅速な回答、感謝いたします。
ありがとうございました。

WindowsInstaller SDK のドキュメント…英語は苦手ですがまた読んでみます！
1

スキルアップ／キャリアアップ（JOB@IT）