none
VS2008のインストーラーでのユーザーのアプリケーションデータフォルダに関して RRS feed

  • 質問

  • VistaでVS2008のインストーラーを作成しています。

    ユーザーのアプリケーションデータフォルダにプログラム間で情報を共有するためにファイルを置いています。
    インストールも上手く行き、プログラム間で情報を共有も上手く行き、問題なく動いているようにも思えいます。

     

    ただ、以下3点のことがあります。

     

    1.対象のファイルがインストーラプロジェクトのファイルシステムのアプリケーションデータフォルダの

        ところで、ブルーのギザギザの下線が出て何かを警告しているようです。

     

    2.プロジェクトのビルド前の検証で、
       ”警告: ファイル 'XXXX.XXX' はユーザーのプロファイル フォルダにインストールすると、

        すべてのユーザーが使用できない可能性があるので、ここにインストールできません。”と警告が出ます。

     (実際にはプロファイル フォルダではありませんが、アプリケーションデータフォルダにインストールされ問題ありません)

     

    3.ユーザーAでインストールし、ユーザーBに切り替え動かしますとBでもアプリケーションデータフォルダに

        ファイルが出来て動いています。 しかし、再度ユーザーAに戻りアンインストールすると、ユーザーBだ

        ファイルが消され、ユーザーAのものが消されません。

     

       再度ユーザーAでインストールした時、新しいものがインストールされず、古いものが残ったままです。
       新しいバージョンでファイルの内容が変わった時、プログラムが正常に動作しなくなる恐れがあります。

     


    以上の点よろしくお願いします。

    2008年12月9日 1:02

回答

  • まず、基本事項っぽいものを書きます。

     

    ・プログラムで使用するファイルで、ユーザ環境で書き換えることのないファイル

     →Program Files以下でOK。

    ・プログラムで使用するファイルで、ユーザ環境で書き換えることのあるファイルで、ユーザ個別で作成しても問題ないファイル

     →プロファイルフォルダ以下のApplication Data等

    ・プログラムで使用するファイルで、ユーザ環境で書き換えることのあるファイルで、全ユーザで共通にしなければならないファイル

     →All Users以下で、インストーラでアクセス許可を設定したフォルダ

     

     クサキ さんからの引用

    ユーザーのアプリケーションデータフォルダにプログラム間で情報を共有するためにファイルを置いています。

    この「プログラム間で情報を共有する」とはどのようなものでしょうか。

     

     クサキ さんからの引用

    2.プロジェクトのビルド前の検証で、
       ”警告: ファイル 'XXXX.XXX' はユーザーのプロファイル フォルダにインストールすると、

        すべてのユーザーが使用できない可能性があるので、ここにインストールできません。”と警告が出ます。

     (実際にはプロファイル フォルダではありませんが、アプリケーションデータフォルダにインストールされ問題ありません)

    Application Dataは通常、プロファイルフォルダの下にあるため、警告は正しく、そして問題があるように見受けられます。

     

     クサキ さんからの引用

    3.ユーザーAでインストールし、ユーザーBに切り替え動かしますとBでもアプリケーションデータフォルダに

        ファイルが出来て動いています。 しかし、再度ユーザーAに戻りアンインストールすると、ユーザーBだ

        ファイルが消され、ユーザーAのものが消されません。

    よく分かりません。

    インストーラで作成したファイルを消すのではないのでしょうか?

    レジストリか何かを見て、消すファイルが変わるのでしょうか?

     

    Application Dataフォルダに置くファイルは、設定ファイル等、ユーザ環境で作成・更新するファイルに留めるべきです。

    また、全てのユーザのApplication Dataフォルダを対象にインストール・アンインストールすることは困難かもしれません。

    (後からユーザが追加されたり、ユーザが削除されたりする可能性がある)

    2008年12月9日 14:22
    モデレータ
  • VirtualStore に書き込まれてしまうのは、Vistaに対応したアプリケーションになっていないからですね。まずはそこから対応が必要かと。

     

    そのうえで、ユーザー間の共有データはCommonAppDataFolder 配下に入れるのが正しい在り方です。

     

    ですが、実際にVistaで確認するとわかりますが、アクセス権がちょっと厳しいので、その部分は注意が必要です。

    具体的には、読む・書くはOKだけど、削除はNGという形ですね。

     

    なぜ、このような格好なのかは知りませんがそうなってます。

     

    それと、Application Data は一方的に書く場合だったか読む場合だったかだけアクセスできる特殊なリンク(のようなもの)です。

    SHGetSpecialFolderLocation とか使ってアクセスしてる分には、全く問題ありませんよ。単にわかりやすいからそう書いてるだけだと思います。

     

    翻って最初の質問部分。

    1.対象のファイルが...

    青の波線なので何か警告が出てるんだと思いますが、その内容が記載されていないのでわかりません。

    他の人に検証してもらいたいのであれば、それを再現する方法を明記してください。

     

    2.プロジェクトのビルド前の検証で

    書いてあるとおりの意味の警告です。

    インストーラの設定がすべてのユーザーへのインストールを認める形になっている場合、特定のユーザー固有のフォルダへのインストールはなにがあっても絶対にやってはいけません。

    ただし、実行時の様々な状況からそれを回避する手段を持っている可能性があるため(VSのセットアッププロジェクト上ではできませんが)、警告を出すだけにとどめているものと思います。

     

    3.ユーザーAでインストールし

    自動修復が動いているとかありませんか?

    なにもなくそこにできているということはたぶんないと思うのですが。。。あるんだろうか?

     

     

     

    アンインストール時に別のアカウント(アンインストールを行っているアカウント以外のアカウント)のフォルダを探すのは実質的にはできませんよ。

    管理者権限があれば潜れますので、見ることかなわずではありませんが、インストーラはフォローしてくれませんので、自分でコード書くことになります。

     

    それが嫌なら、Multiple Instance とかを調べてください。日本語情報を見つけられていないのと、少なくとも今の自分の状況からは必要とはなっていない感じなのとで全く読んでませんけど。。。

    もしかしたら役立つ情報があるかもしれません。

     

    それと。。。たぶん、インストーラに要求されている能力がVSセットアッププロジェクトでできることのリミットを超えていると思います。

    InstallShield(Expressではないほう)や、WiXなどもっと高度な次元で制御が可能なインストーラ作成ツールの利用を検討したほうが良いと思いますよ。

     

    2008年12月11日 8:11

すべての返信

  • まず、基本事項っぽいものを書きます。

     

    ・プログラムで使用するファイルで、ユーザ環境で書き換えることのないファイル

     →Program Files以下でOK。

    ・プログラムで使用するファイルで、ユーザ環境で書き換えることのあるファイルで、ユーザ個別で作成しても問題ないファイル

     →プロファイルフォルダ以下のApplication Data等

    ・プログラムで使用するファイルで、ユーザ環境で書き換えることのあるファイルで、全ユーザで共通にしなければならないファイル

     →All Users以下で、インストーラでアクセス許可を設定したフォルダ

     

     クサキ さんからの引用

    ユーザーのアプリケーションデータフォルダにプログラム間で情報を共有するためにファイルを置いています。

    この「プログラム間で情報を共有する」とはどのようなものでしょうか。

     

     クサキ さんからの引用

    2.プロジェクトのビルド前の検証で、
       ”警告: ファイル 'XXXX.XXX' はユーザーのプロファイル フォルダにインストールすると、

        すべてのユーザーが使用できない可能性があるので、ここにインストールできません。”と警告が出ます。

     (実際にはプロファイル フォルダではありませんが、アプリケーションデータフォルダにインストールされ問題ありません)

    Application Dataは通常、プロファイルフォルダの下にあるため、警告は正しく、そして問題があるように見受けられます。

     

     クサキ さんからの引用

    3.ユーザーAでインストールし、ユーザーBに切り替え動かしますとBでもアプリケーションデータフォルダに

        ファイルが出来て動いています。 しかし、再度ユーザーAに戻りアンインストールすると、ユーザーBだ

        ファイルが消され、ユーザーAのものが消されません。

    よく分かりません。

    インストーラで作成したファイルを消すのではないのでしょうか?

    レジストリか何かを見て、消すファイルが変わるのでしょうか?

     

    Application Dataフォルダに置くファイルは、設定ファイル等、ユーザ環境で作成・更新するファイルに留めるべきです。

    また、全てのユーザのApplication Dataフォルダを対象にインストール・アンインストールすることは困難かもしれません。

    (後からユーザが追加されたり、ユーザが削除されたりする可能性がある)

    2008年12月9日 14:22
    モデレータ
  • 本体プログラムとその立ち上げの条件を設定するプログラムを作っています。
    その橋渡しをするデータを保管するファイルの置き場所はどこが良いかと言うことです。
    ファイルは設定ファイル等、ユーザ環境で作成・更新するファイルと言って良いのでしょうか。

     

    レジストリは何も見ていませんし、意識的に触ってもいません。
    ファイルシステムエディッタで出来る範囲で行っています。

     

    インストールしたファイルはアンインストールの時には全て完全に消したいだけです。
    次のインストールの邪魔にならないようにしたいだけです。

     

    Vista以前では共通ファイルフォルダを使っていました。

    Vistaでは、ここを使うことは推奨されていないと理解しています。

    ただ、互換性のためにVirtualStoreに転送され、そこのファイルを

    読み書きし動作はしているものと理解しています。
    (”Vistaでの共通ファイルフォルダーに関して”のCatTail さんのコメントより)


    アンインストールの時、共通ファイルフォルダにあるファイルは消されますが、
    VirtualStoreのものは残ったままです。
    この状態で再インストールすると、共通ファイルフォルダにファイルはインストール

    されますが、プログラムの実行ではVirtualStoreの古いファイルを読み書きします。
    特に、バージョンアップでこのファイルの形が変わっている時は、

    本体のプログラムが暴走する恐れもあります。

     

    ご指摘のプログラムファイルフォルダ(ProgramFilesFolder )
    ユーザーの共通アプリケーションデータフォルダ(CommonAppDataFolder)
    なども同様の動きでした。

     

    そこで、ユーザーのアプリケーションデータフォルダ(AppDataFolder)を使うのかと思っていました。
    VirtualStoreにファイルの転送はされず、インストール先のファイルを読み書きしています。
    VS2008のインストーラ作成時の警告と、複数のユーザーでのアンインストールの

    不都合を除けば、私の期待している動きです。

     


    (Application Data とは、ユーザーのアプリケーションデータフォルダ(C:\Users\XXX\Roaming)
      のことではないのでしょうか?
      VistaのエクスプローラでApplication Dataをクリックしてもアクセスが拒否されましたと出て、

      Vistaでは実体が無いようなきがするのですが。)


     

    2008年12月11日 1:45
  • VirtualStore に書き込まれてしまうのは、Vistaに対応したアプリケーションになっていないからですね。まずはそこから対応が必要かと。

     

    そのうえで、ユーザー間の共有データはCommonAppDataFolder 配下に入れるのが正しい在り方です。

     

    ですが、実際にVistaで確認するとわかりますが、アクセス権がちょっと厳しいので、その部分は注意が必要です。

    具体的には、読む・書くはOKだけど、削除はNGという形ですね。

     

    なぜ、このような格好なのかは知りませんがそうなってます。

     

    それと、Application Data は一方的に書く場合だったか読む場合だったかだけアクセスできる特殊なリンク(のようなもの)です。

    SHGetSpecialFolderLocation とか使ってアクセスしてる分には、全く問題ありませんよ。単にわかりやすいからそう書いてるだけだと思います。

     

    翻って最初の質問部分。

    1.対象のファイルが...

    青の波線なので何か警告が出てるんだと思いますが、その内容が記載されていないのでわかりません。

    他の人に検証してもらいたいのであれば、それを再現する方法を明記してください。

     

    2.プロジェクトのビルド前の検証で

    書いてあるとおりの意味の警告です。

    インストーラの設定がすべてのユーザーへのインストールを認める形になっている場合、特定のユーザー固有のフォルダへのインストールはなにがあっても絶対にやってはいけません。

    ただし、実行時の様々な状況からそれを回避する手段を持っている可能性があるため(VSのセットアッププロジェクト上ではできませんが)、警告を出すだけにとどめているものと思います。

     

    3.ユーザーAでインストールし

    自動修復が動いているとかありませんか?

    なにもなくそこにできているということはたぶんないと思うのですが。。。あるんだろうか?

     

     

     

    アンインストール時に別のアカウント(アンインストールを行っているアカウント以外のアカウント)のフォルダを探すのは実質的にはできませんよ。

    管理者権限があれば潜れますので、見ることかなわずではありませんが、インストーラはフォローしてくれませんので、自分でコード書くことになります。

     

    それが嫌なら、Multiple Instance とかを調べてください。日本語情報を見つけられていないのと、少なくとも今の自分の状況からは必要とはなっていない感じなのとで全く読んでませんけど。。。

    もしかしたら役立つ情報があるかもしれません。

     

    それと。。。たぶん、インストーラに要求されている能力がVSセットアッププロジェクトでできることのリミットを超えていると思います。

    InstallShield(Expressではないほう)や、WiXなどもっと高度な次元で制御が可能なインストーラ作成ツールの利用を検討したほうが良いと思いますよ。

     

    2008年12月11日 8:11
  • >VirtualStore に書き込まれてしまうのは、Vistaに対応したアプリケーションに
    >なっていないからですね。まずはそこから対応が必要かと。

     

    SQLなども使っていませんし、スタンドアローンのプログラムで単純なものだと思います。
    情報のやり取りのためのファイルを読み書きしているのはVS2008でのMFCのDLLの関数です。
    ユーザーインターフェースにVB6.0を使っています。
    このVB6.0作成のプログラムが、Vistaに対応したアプリケーションではないということでしょうか?


    >それと、Application Data は一方的に書く場合だったか読む場合だったかだけアクセス
    >できる特殊なリンク(のようなもの)です。
    >SHGetSpecialFolderLocation とか使ってアクセスしてる分には、全く問題ありませんよ。
    >単にわかりやすいからそう書いてるだけだと思います。

    聞きたかったのは、Application Data はAppDataFolderやCommonFilesFolderのような
    指定の仕方ではどうしていしたら良いかということです。

     

    >1.対象のファイルが...
    >青の波線なので何か警告が出てるんだと思いますが、その内容が記載されていないのでわかりません。
    >他の人に検証してもらいたいのであれば、それを再現する方法を明記してください。


    青の波線だけで、何のメッセージもでません。
    2.を簡便的に表現しているのかと思っています。
    やっていることは簡単で、AppDataFolderにファイルを追加しただけです。


    >2.プロジェクトのビルド前の検証で
    >書いてあるとおりの意味の警告です。
    >インストーラの設定がすべてのユーザーへのインストールを認める形になっている場合、
    >特定のユーザー固有のフォルダへのインストールはなにがあっても絶対にやってはいけません。


    AppDataFolderはインストール後にアプリケーションプログラムが利用するところで、
    インストールでは空のフォルダを作成するだけと考えたら良いですね。


    >3.ユーザーAでインストールし
    >自動修復が動いているとかありませんか?
    >なにもなくそこにできているということはたぶんないと思うのですが。。。あるんだろうか?


    ユーザーAと同じものがユーザーBのAppDataFolderにも出来ます。
    どこかにあるファイルで自動修復したとも考えられますが、
    ユーザーAのAppDataFolderのものは変更ができませんので区別がつきません。
     
    >アンインストール時に別のアカウント(アンインストールを行っているアカウント以外のアカウント)の
    >フォルダを探すのは実質的にはできませんよ。
    話は逆で、ユーザーAでアンインストールしているのにユーザーBのものが消されています。
    最後に動かされたユーザーのものが消されたのではないかと考えています。


    >管理者権限があれば潜れますので、見ることかなわずではありませんが、
    >インストーラはフォローしてくれませんので、自分でコード書くことになります。
    >それが嫌なら、Multiple Instance とかを調べてください。日本語情報を見つけられていないのと、
    >少なくとも今の自分の状況からは必要とはなっていない感じなのとで全く読んでませんけど。。。

     

    あまり難しいことをする能力がありません。
    CommonAppDataFolder利用はVirtualStoreにファイルが転送され同じファイルが複数でき、
    ややこしくなりそうですが、ファイルの名前を変えれば、次のインストールの時も新しいファイル

    が利用できそうです。
    AppDataFolderの利用は一つのユーザーだけにインストールしたら思っている動きです。
    どちらかで、とりあえずは行こうかなと思っています。

     

    >それと。。。たぶん、インストーラに要求されている能力がVSセットアッププロジェクトで
    >できることのリミットを超えていると思います。
    >InstallShield(Expressではないほう)や、WiXなどもっと高度な次元で制御が可能なインストーラ作成ツール
    >の利用を検討したほうが良いと思いますよ。


    それほどの高望みとも思っていませんでしたが、大変なんですかね。


     

    2008年12月12日 6:06
  •  クサキ さんからの引用

    SQLなども使っていませんし、スタンドアローンのプログラムで単純なものだと思います。
    情報のやり取りのためのファイルを読み書きしているのはVS2008でのMFCのDLLの関数です。
    ユーザーインターフェースにVB6.0を使っています。
    このVB6.0作成のプログラムが、Vistaに対応したアプリケーションではないということでしょうか?

    VB6.0のプログラム(EXEですよね?)がVistaに対応したものができるか?についてはわかりません。動くかどうかと対応できるかは別問題ですので。

     

    このあたりは、MSDN探してもうまく見つけられないので

    http://blogs.wankuma.com/jitta/archive/2006/09/26/39667.aspx

    とか読んでみるとよいかと。。。

     

    検索キーワードが悪いのかな?MSDNライブラリからうまく探し出せない。。。orz

     クサキ さんからの引用

    あまり難しいことをする能力がありません。
    CommonAppDataFolder利用はVirtualStoreにファイルが転送され同じファイルが複数でき、
    ややこしくなりそうですが、ファイルの名前を変えれば、次のインストールの時も新しいファイル

    が利用できそうです。

    "VirtualStore UAC" で検索すると出てくるページとかいろいろ読んでみるとよいかと。

     

     クサキ さんからの引用

    それほどの高望みとも思っていませんでしたが、大変なんですかね。

    いえ、VSセットアップでできることをすでに超えてるからにすぎません。

    CommonAppDataFolder とか、VSセットアップでは扱えないはずです。なので、その部分でキャパシティオーバーしてるにすぎません。

    その結果として、あちこちにしわ寄せがきているということになると思います。

    2008年12月15日 6:39