none
同一端末に同一アプリケーションを複数インストール RRS feed

  • 質問

  • こんにちは。お世話になります。

    現在、Visual Studio 2008(VB)でXP・Vista向けスタンドアロンWindowsアプリを開発しています。

    もともとVisualStudio付属のインストーラ作成ツールを使用するつもりでしたが、
    特殊な事情があり、同じアプリを同一端末の別フォルダに複数インストールし、
    各フォルダにある別々のDBを参照して使用する要件があります。

    こういった場合の最適な方法についてご教示いただければと思います。
    WindowsInstallerであると同一アプリの複数回インストールというのは
    考え方としてはないと思っていますので、
    現在考えている方法は以下の通りです。

    ・インストーラは自作(VB.Netで開発)し、実行ファイルおよび必要なライブラリの
    フォルダ配置およびショートカットの作成は自作インストーラにて行う
    ・その場合、.Net Framework3.5が入っていないとそもそもインストーラが動作
    しないため、.Net Frameworkのインストールをチェックし、なければ.Net Framework
    のインストーラを起動し、最終的に自作インストーラを起動するWSHを作成。

    あまりアプリケーション環境に精通していないため、他の手段や、上記手段での
    問題点などありましたら教えていただきたいと考えた次第です。

    よろしくお願いいたします。

    2009年8月7日 11:00

すべての返信

  • 現在、Visual Studio 2008(VB)でXP・Vista向けスタンドアロンWindowsアプリを開発しています。

    もともとVisualStudio付属のインストーラ作成ツールを使用するつもりでしたが、
    特殊な事情があり、同じアプリを同一端末の別フォルダに複数インストールし、
    各フォルダにある別々のDBを参照して使用する要件があります。

    こういった場合の最適な方法についてご教示いただければと思います。
    WindowsInstallerであると同一アプリの複数回インストールというのは
    考え方としてはないと思っていますので、
    現在考えている方法は以下の通りです。
    要件にもよりますが、複数インストールとはどのような状況なのでしょうか?
    同一端末内の複数のユーザーが個々に使うだけならばPer Userインストールでもよさそうですし、そもそも参照するデーターファイルを分離するだけのような。
    一人のユーザーが複数インスタンスを持つなら、それはインストール行為でよりもアプリ起動後に複数の設定を持てた方が扱いやすいですし。たとえばMozilla Firefoxなんかはプロファイルを指定して起動できたはずです。
    サービスプロセスが複数インスタンスを持つなら、SQL Serverみたいにサービス名から変わってきますね。

    質問に直接答えるならInstalling Multiple Instances of Products and Patches というのがあります。
    リンク先にも書かれていますが、
    まずMSIを作成しておいて、それに対するMSTでproduct codeを書き換えます。ついでにインストール先ディレクトリも変えるといいでしょう。


    ・インストーラは自作(VB.Netで開発)し、実行ファイルおよび必要なライブラリの
    フォルダ配置およびショートカットの作成は自作インストーラにて行う
    ・その場合、.Net Framework3.5が入っていないとそもそもインストーラが動作
    しないため、.Net Frameworkのインストールをチェックし、なければ.Net Framework
    のインストーラを起動し、最終的に自作インストーラを起動するWSHを作成。

    あまりアプリケーション環境に精通していないため、他の手段や、上記手段での
    問題点などありましたら教えていただきたいと考えた次第です。
    インストーラを.NETで作成するのは感心しません。ネイティブにすべきでしょう。どうせWSHを使うならWSHで全部書いてしまうとか。

    何にせよ、バージョンアップが大変そうですね。
    2009年8月8日 0:32
  • アプリとDBでインストーラをそれぞれ作るのが良いのではないでしょうか?
    このような感じで。

    * Hoge App Installer
    * Hoge Data 1 Installer
    * Hoge Data 2 Installer
    * ...

    > インストーラを.NETで作成するのは感心しません。
    同感です。Vista では C:ドライブへのアクセスが妙に制限されていたりするのでWSHだと面倒になりそうな予感がします。


    Toshiya TSURU http://www.google.com/profiles/turutosiya
    2009年8月10日 1:16
  • 要件にもよりますが、複数インストールとはどのような状況なのでしょうか?
    同一端末内の複数のユーザーが個々に使うだけならばPer Userインストールでもよさそうですし、そもそも参照するデーターファイルを分離するだけのような。
    一人のユーザーが複数インスタンスを持つなら、それはインストール行為でよりもアプリ起動後に複数の設定を持てた方が扱いやすいですし。たとえばMozilla Firefoxなんかはプロファイルを指定して起動できたはずです。
    サービスプロセスが複数インスタンスを持つなら、SQL Serverみたいにサービス名から変わってきますね。

    質問に直接答えるならInstalling Multiple Instances of Products and Patches というのがあります。
    リンク先にも書かれていますが、
    まずMSIを作成しておいて、それに対するMSTでproduct codeを書き換えます。ついでにインストール先ディレクトリも変えるといいでしょう。

    ご回答、また有用な情報ありがとうございます。
    今回の場合は、一人のユーザが複数インスタンスを持ちます。
    佐祐理さんのおっしゃるとおり、アプリ起動後にインスタンスを選ぶような形にしたかったのですが、
    すでに動いている現行システムがフォルダ分けで別exe起動であり、踏襲せざるを得ませんでした。

    Installing Multiple Instances of Products and Patches ですが、確かに使えそうです!!
    ただ、お恥ずかしい話ですが、リンクの3つのページを読んだのですが、英語読解力が足りないのか、理解仕切れていません。
    msiを実行する際、TRANSFORMS=:XXX.mstでmstを指定、MSINEWINSTANCE=1をコマンドラインに付与すればできそうだ、
    というところまでは分かったのですが、.mstというのは何者で、どこから出てくるのか(ファイルを作る必要がある・・?)頻繁に出てくる
    instance transformsという行為が具体的に何を指すのかよくわかりません。また、インストール先ディレクトリをどのように変更する
    のかも今のところつかめていません。
    どのあたりに書いてある、でも良いのでヒントをいただけると助かるのですが・・・申し訳ありません。
    2009年8月10日 10:41
  • Toshiya TSURU さん、ご回答ありがとうございます。

    今回の場合、アプリとDBはセットで同じフォルダにインストールしなければならないため、
    (そのセットで複数インストールする必要がある)分けてインストーラを作成するのが有用かまだ
    判断付かないのですが、ひとつでインストールするのが無理であれば検討したいと思います。

    >同感です。Vista では C:ドライブへのアクセスが妙に制限されていたりするのでWSHだと面倒になりそうな予感がします。

    ありがとうございました。開発機がXPでVistaでは十分に検証ができていないため、
    情報をいただいて助かります。
    .Netで作成しないように考えたいと思います。

    2009年8月10日 10:48
  • msiを実行する際、TRANSFORMS=:XXX.mstでmstを指定、MSINEWINSTANCE=1をコマンドラインに付与すればできそうだ、
    というところまでは分かったのですが、.mstというのは何者で、どこから出てくるのか(ファイルを作る必要がある・・?)頻繁に出てくる
    instance transformsという行為が具体的に何を指すのかよくわかりません。また、インストール先ディレクトリをどのように変更する
    のかも今のところつかめていません。
    どのあたりに書いてある、でも良いのでヒントをいただけると助かるのですが・・・申し訳ありません。
    個々の質問に答えることはできまずが、全体としてはWindows Installer を理解していただくほかありません。
    ややこしくて私も理解しきれていませんがw

    ざっと概要を
    Windows Installerは全てデーターベースのテーブル として管理されていて、MSIファイルというのはそのテーブルの実体です。
    MSTとはMSIの中のテーブルを上書きするためのレイヤーファイルのようなものと考えてください。
    たとえば、インストーラに含まれているメッセージを上書きすることでインストーラを翻訳できます。
    なので、先に述べたようにproduct codeを書き換えて別アプリと見せかけたり、デフォルトのインストール先を変更したりもできます。

    Windows SDKをインストールするとOrcaというツールのインストーラがインストールされます。これを使うとMSIやMSTの中身を表示・編集できます。そのほかにもツールがいろいろと インストールされます。
    ちなみにtransformの生成周りは落とし穴があったような気がします。


    「すでに動いている現行システムがフォルダ分けで別exe起動であり、踏襲せざるを得ませんでした。」とありますが、どこまで踏襲する必要があるのでしょうか?
    個々のフォルダにEXEの実体が存在することが必須なのでしょうか? 複数いるように見せかける、引数付きで本体を起動するショートカットを置くとか、そんなんじゃダメなんでしょうかね。
    というか、現行システムのインストーラがどう作られていたのかも気になります。
    2009年8月11日 3:26
  • 佐祐理さん、ご親切にありがとうございます。

    WindowsInstallerを理解するというところまでは行っていませんが
    お蔭様で、大分分かってきました。

    Orcaは以前使用したことがあります。
    Orcaを使ってmstファイルを作成することもできました。
    ただ、mstファイルを使用するとなるとmsi起動しなければならず、
    Visual Studioを使用して作成したSetup.exeが使用できないのでは
    ないかと思っております。(ひょっとしてやりようがあるのかもしれませんが、調査中ですが)
    そうなると.Net Frameworkのインストールやマージモジュールのインストールは
    自作するということになり、最初のWSHも含めSetup.exe自作方法に悩んでいます。
    mstを使用してかつVisualStudioで生成したSetup.exeが使用できればかなり助かるのですが・・

    ですが、プロダクトコード上書き+自作という方向で見えてはきました。
    ありがとうございます。

    >「すでに動いている現行システムがフォルダ分けで別exe起動であり、踏襲せざるを得ませんでした。」とありますが、どこまで踏襲する必>要があるのでしょうか?
    >個々のフォルダにEXEの実体が存在することが必須なのでしょうか? 複数いるように見せかける、引数付きで本体を起動するショートカッ>トを置くとか、そんなんじゃダメなんでしょうかね。
    >というか、現行システムのインストーラがどう作られていたのかも気になります。

    確かにそうですね。現行がフォルダごとにDBを持っておりその作りも踏襲したため、今のような作りに
    なってしまっています。また、フォルダが別であれば別アプリのように同時起動も可能とする作りだったり
    します。
    ちなみに現行システムはとても古く(VB2)ソースもなく、インストーラはおそらく自作でインストール先を
    入力させてほぼフォルダを置くだけ、アンインストールはフォルダ削除です。
    ですので、ユーザもなるべく同じようにしたいようです。(バージョンアップの可能性はほぼゼロ)
    2009年8月11日 12:09
  • ちょっと時間が経ってしまったので、旬を逃しちゃったかしら。。。

    VSの setup.exe を独自にビルドすることもできます。インフラストラクチャとかなんとか書かれてますが、
    Microsoft.Build.Tasks.Deployment.Bootstrapper 名前空間の BootstrapperBuilder オブジェクトほかを利用して、任意の設定でビルドできます。

    実際作ったこととかありますが、どうも埋め込み起動パラメータは用意できないみたいなんですよねー<出来るといろいろ便利なんですが...
    なので、パラメータが必要という場合は、msi をパラメータ付きで呼び出すだけの単純なEXEを作成しておいて、それを実行するようにブートストラッパーを設定するのがお勧めです。

    Webダウンロードなのでファイルが1つじゃないとだめだ!ということがなければこれで大半はフォローアップできます。

    あと、MSI や WindowsInstaller なネタは、MSI-ML でも扱ってますので、興味があったら覗いてみてください。こっちは宣伝w


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    2009年8月17日 5:42
  • とっちゃん さん

    すばらしい情報をありがとうございます!
    ちょうど、そろそろ決めにかからなくてはいけないところまで来ていたので
    大変有難いです。

    とっちゃんさんのブログで、ブートストラッパを自分でビルドするという記事を拝見したので、
    それを参考に試しにプロジェクトを作ってみたところ、あっさりできたので感動しました。
    が、.net frameworkを2.0から3.5にすると落ちるようになり、ProductCodeをどうやって
    知ればよいのか悩んでいます。
    VSで同じようにインストーラを作って、prjファイルを見ると、2.0をただ3.5に変えれば良い
    ようにも見えるのですが・・

    何か根本的なことが抜けているような気もしますが。

    MSDNはざっと見たので引き続きいろいろ試してみたいと思いますが、
    基本的に使い方の情報が見当たらないように思うので、何か情報があれば
    ヒントをいただけると助かります。
    ありがとうございます!

    2009年8月24日 8:50
  • VS2008 で作っているんですよね?
    であれば、サンプルの
    buildSettings.ProductBuilders.Add( builder.Products.Product( "Microsoft.Net.Framework.2.0" ).ProductBuilder );

    buildSettings.ProductBuilders.Add( builder.Products.Product( "Microsoft.Net.Framework.3.5" ).ProductBuilder );
    の様に変更します(SP1であればまた文字列が違う)。

    もちろん、ビルドは、.NET Framework 3.5 SDK(SP1が必要ならそのSDK)がインストールされている環境で行う必要があります。
    具体的にどのような文字列を与えるか?は、
    C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages
    の各フォルダにある product.xml の ProductCode 属性をみてください(先頭にあるのですぐに見つけられます)。

    あとは、VS2005 と VS2008 では若干違うので、ヘルプをみて違いをチェックする必要があります。

    ポイントとしては...このモジュール、2.0 と 3.5 で違うやつなんですよ。その部分じゃないかと思いますよ。
    私も引っ掛かったんでwww


    わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/
    2009年8月24日 9:05
  • とっちゃん さん
    ご親切にありがとうございます!!

    >VS2008 で作っているんですよね?

    そうです。
    おっしゃる通り、古いモジュールを参照設定していました。
    しかも、MSDNでProductBuilderを見ると3.5のヘルプにも
    関わらずアセンブリがMicrosoft.Build.Tasks.dllとなっていて
    これは間違いなんですね。更なるトラップでした。

    お陰様でSetup.exeが動きました。ありがとうございます。

    後は、肝心のmstを使ったコマンドラインからのmsi実行が
    うまく行っていないので更に格闘してみます。
    MSI-MLは以前から気になっていました。覗かせていただきます。

    2009年8月27日 9:19
  • その後の経過ですが、

    orcaでtransformfileのproductcodeを書き換え、コマンドラインからmsiexecを実行したところ、
    (msiexec /I Hoge.msi TRANSFORMS=Hoge.mst MSINEWINSTANCE=1 /qb)
    「このプロダクトの新しいバージョンが既にインストールされているためインストールできません」
    というエラーが出てしまいます。
    どうも、別アプリとは認識されていないようです。

    そもそも、msi本体のproductcodeを書き換えても、同様の現象が発生します。
    msi本体のpackagecodeも変更すると別アプリと認識されるようでしたが・・
    mstでpackagecodeの変更はできないようなので。

    そうなると、
    Installing Multiple Instances of Products and Patches
    でNewInstanceと説明されていることは何なのだろう、
    と考えてしまいますが・・
    MSINEWINSTANCEプロパティの意味合いもよくわかりません。
    相変わらず英語を読み落としている可能性もありますが。

    とにかく情報が少ないうえ、そろそろ、時間的にもリミットが近いので、
    とっちゃんさんよりご教示いただいた方法でBootStrapperを作成し、
    ファイル配置等は自作する方向にせざるを得なくなってきました。

    もし、情報をお持ちの方がいらっしゃいましたら、引き続きよろしくお願いいたします。
    2009年8月28日 8:16
  • ↓DOBON.NET トップページ
    http://dobon.net/
    ↓デプロイメントプロジェクトによるアップデート
    http://dobon.net/vb/dotnet/deployment/upgrades.html
    (抜粋)
    前に述べたとおり、Major Upgradeでは別の製品として扱われるため、古いバージョンが既にインストールされていてもそれとは別の製品としてインストールされます。つまりMajor Upgradeは前のバージョンを上書きして(あるいは置き換えて)インストールするということではありません。前のバージョンと同じフォルダにインストールすれば、ファイルを上書きすることはできますが、コントロールパネルの「プログラムの追加と削除」には古いバージョンが残されたまま、新しいバージョンの項目が追加されます。つまり、新しいバージョンを古いバージョンに置き換える場合は、古いバージョンをアンインストールしてから新しいバージョンをインストールしなければなりません。それを自動的に行うようにするのが、RemovePreviousVersions プロパティです。
    なおこのようなMajor UpgradeではUpgradeCodeが使われるため、UpgradeCodeは絶対に変えてはいけません。

    ↑つまり、ソリューションの中にセットアッププロジェクトをいくつか作成し
    UpgradeCode をバラバラにしておけばインストールできます。
    setup.exe もばらばらになってしまうので
    順次実行するようなスクリプトを別途作成すればよいかと。

    2009年8月28日 9:07
  • あんにんご さん
    ご回答ありがとうございます。
    教えていただいたページは、大変勉強になります。

    やはり、Major UpgrateではPackageCodeを変える必要がある=
    別セットアッププロジェクトが必要となるんですよね。
    今回のケースは、1端末に何通り必要になるのかが不明で、
    リリース後、追加インストールがいつ決まるのかも不定で、
    保守担当者がインストーラを用意するため、開発環境で
    インストーラを再ビルドする、等の手順も不可能なのです。
    (ソリューションの中に「いくつか」のいくつが決められない)
    せいぜい、orcaでmstをいじるくらいであれば、マニュアルを
    つくればギリギリOKかなという感じだったのですが、
    それも微妙なくらいで・・

    何か私が勘違いをしている可能性もありますので、
    その場合はご教示いただけると幸いです・・

    ありがとうございました。

    2009年9月3日 8:16
  • なるほど、インストールする数は定まらないのですね。
    それだと最初に書かれている↓の方法は妥当に感じられました。
    ・インストーラは自作(VB.Netで開発)し、実行ファイルおよび必要なライブラリの
    フォルダ配置およびショートカットの作成は自作インストーラにて行う

    新規インストールだけ msi でおこなって、2回目からはコピーするという手も… 
    でもインストールの仕組みが複雑になってしまいますね。 
    ↑これは思いつきレベルですので気にしないでください(v v)
    2009年9月3日 12:16
  • あんにんご さん

    コメント、ありがとうございます。
    返信遅くなり申し訳ありません。

    >それだと最初に書かれている↓の方法は妥当に感じられました。

    結局、その方法に近いやり方で実現することになりそうです。
    勇気付けられました・・
    Vistaのショートカット作成などに少々てこずりましたが、
    何とか実現にこぎつけそうです。

    >新規インストールだけ msi でおこなって、2回目からはコピーするという手も… 
    >でもインストールの仕組みが複雑になってしまいますね。 

    最初に検討していた方法がまさにそれでした。
    ただ、インストール先が1度目か2度目か管理できないのと、
    アンインストールが複雑になってしまうため、
    区別しない方法を模索していました。


    Installing Multiple Instances of Products and Patches
    について謎のまま残ってしまったのが残念ですが、
    皆様のおかげで何とかなりそうです。
    大変勉強になりました。
    ありがとうございました。
    2009年9月15日 1:40