VB.netで作成したアプリケーションがWindows7上で動作しない。

Question

開発環境：WindowsXP

開発ツール：VB2005（ｲﾝｽﾄｰﾗｰはVC）

上記の開発環境で構築したアプリケーションをCD-ROMにしてWindows7にインストールしたところ、実行できなかったり、ﾃﾞｽｸﾄｯﾌﾟにあったショートカットが消えたりといろいろと不具合が出ております。

基本的には検証時にWindows7でも試して見てはいるので問題ないと思われたのですが、検証時にWindows7　Professionalで検証だったのでそれ以外がダメなのでしょうか。また、Windows7の32bit版と64bit版での差異で動作するものしないものが変わってくるのでしょうか？

かなり漠然としていて申し訳ありませんが、宜しくお願い致します。

Answer 1

インストーラはVC。。。というのは独自？ま、ここは単なる個人的な興味の範囲なのでどうでもいいとして。。。

よくある話だと。。。

1. インプロセスのCOMや Native のDLL(Systemのものではない)をP/Invoke しているが、呼び出し元のManaged アプリは、ANY CPUで作成していた。
2. Program Files(86)のように、64bit環境だと異なるパスになるのにそれを考慮していなかった。
3. レジストリなどのリダイレクトが原因でインストーラが設定した情報が見えなくなっていた。

というあたりですかね。

それ以外だと、もう少し細かい状況がわからないとなんとも言えません。

 

---

わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/

Answer 2

とっちゃんさん　回答ありがとうございます。

>インストーラはVC。。。というのは独自？ま、ここは単なる個人的な興味の範囲なのでどうでもいいとして。。。

>よくある話だと。。。

>　　1.　インプロセスのCOMや Native のDLL(Systemのものではない)をP/Invoke しているが、呼び出し元のManaged アプリは、ANY CPUで作成していた。

ｲﾝｽﾄｰﾗｰ作成や実際にアプリケーション作成をしているのは別会社にしてもらっているので、ここに関しては問い合わせなどしてみます。

>　　2．　Program Files(86)のように、64bit環境だと異なるパスになるのにそれを考慮していなかった。

>　　3．　レジストリなどのリダイレクトが原因でインストーラが設定した情報が見えなくなっていた。

Program Filesは64bit環境だと、インストール時に設定したﾌｫﾙﾀﾞとは異なるﾊﾟｽになるのですか？細かい話なのですが、アプリケーションはVB.netなのですが、DBはAccessのMDBを使用しています。アプリケーション起動時、インストール時に保存したパスで各MDBを参照するような設定となっている為、起動できなかったり、ｴﾗｰが起こる原因と考えても良いのでしょうか？

32bit環境、64bit環境などを意識したことがないもので見当違いの質問をしていたら申し訳ございません。

Answer 3

>　　1.　インプロセスのCOMや Native のDLL(Systemのものではない)をP/Invoke しているが、呼び出し元のManaged アプリは、ANY CPUで作成していた。

ｲﾝｽﾄｰﾗｰ作成や実際にアプリケーション作成をしているのは別会社にしてもらっているので、ここに関しては問い合わせなどしてみます。

自分で作っているわけではないのなら、修正もできないので作成元にバグですと付きつけてしまえばいいだけかと？

>　　2．　Program Files(86)のように、64bit環境だと異なるパスになるのにそれを考慮していなかった。

>　　3．　レジストリなどのリダイレクトが原因でインストーラが設定した情報が見えなくなっていた。

Program Filesは64bit環境だと、インストール時に設定したﾌｫﾙﾀﾞとは異なるﾊﾟｽになるのですか？細かい話なのですが、アプリケーションはVB.netなのですが、DBはAccessのMDBを使用しています。アプリケーション起動時、インストール時に保存したパスで各MDBを参照するような設定となっている為、起動できなかったり、ｴﾗｰが起こる原因と考えても良いのでしょうか？

32bit環境、64bit環境などを意識したことがないもので見当違いの質問をしていたら申し訳ございません。

パス文字列を決め打ち(実行時に取得ではなく、固定値)ではないのなら、特に問題はありません。ただし、Vista以降のOSの場合、書き込みできるファイルは、Program Filesなどのフォルダには配置できなくなっていますので

そのような形にならないようにプログラムを作成する必要があります(場合によっては、インストーラでそのように配置する)。

でも、MDBにアクセスしているということであれば、ANY CPU をやめて、x86 にするだけで解決すると思いますよ。

 

---

わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/

Answer 4

結果的に、64bit版の対応ができていなかったということで話はまとまりました。

64bit版にはCドライブ直下にC:\Program FilesとC:\Program Files(86)と二つのフォルダが存在するようで両方にインストールしても動作しませんでした。

現状、アプリケーションをCD-ROMとして配布してしまっているのでどうにか動かせるように対応したいのですが、対応方法としては何か無いでしょうか？

最初の回答で

>　　2．　Program Files(86)のように、64bit環境だと異なるパスになるのにそれを考慮していなかった。

とありますが、C:\Program Files 以外のところ（例えばCドライブ直下やﾃﾞｽｸﾄｯﾌﾟなど）にインストールすることによって動作するようになるのでしょうか？

また、アプリケーションを互換ﾓｰﾄﾞでWindowsXPﾓｰﾄﾞに変更などすれば動作するのでしょうか？

Answer 5

64bit対応ができていなかったということだとすると。。。インストール先をどうにかすればではなく、ANY CPUではなく、32bit用でビルドしない限り回避できないということだと思います。

こればっかりは作ってる人じゃないとわからんですが...回避策としては

「64bitOSで動かさない」

しか選択肢はないものと思います。

ですので、64bit OSでの利用の場合は、ライセンスのある32bitOSを用意したうえで、仮想PCとして、32bitOSをインストールし、そこで利用する(WindowxXPモードも形としては同じ)とするか、物理的に32bitなOSのインストールされたマシンを用意するかのどちらかになると思います。

---

わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/

Answer 6

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

64bitOSでの回避方法はやはり無いのですね。。。既に配られてしまったアプリケーションなのでどうにか現状で対応したいと思っていたのですが。

一応、作成元に「バグです」と付き返すことになりました。

それから、確認ではあるのですがANY CPU をやめて、x86にすることによって、32bitOS、64bitOSのどちらでも動作するようになるんですよね？

Answer 7

64bitOSでの回避方法はやはり無いのですね。。。既に配られてしまったアプリケーションなのでどうにか現状で対応したいと思っていたのですが。

一応、作成元に「バグです」と付き返すことになりました。

今あるプログラムで何らかの対応策があるかどうかは、開発元じゃないとわかりません。

あくまでも「64bit対応ができていなかった」という仮定のもとに話をしているのであり、それが確定してるかどうかはこの流れだけでは判断しきれない部分があります。

なので「バグです」とするのは何の問題もありません。「実際意図したとおりに動いていない(＝動作していない)」状態なのですよね？

それから、確認ではあるのですがANY CPU をやめて、x86にすることによって、32bitOS、64bitOSのどちらでも動作するようになるんですよね？

 こちらについては、なんとも言えません。x86 モードでビルドしたモジュールは、32bitOS でも 64bitOS でも実行可能です。

ですが、今回問題となっているプログラムがそれで動作するか？とは本質的に関係があるかどうかがわかっていない現状で動作するとは言えません。

「動作する」とは、多少の不具合はあるとしたとしても、「意図したとおりにプログラムが実行できること」を指します。

申し訳ないとは思いますが、現時点で把握できる情報だけで開発者が気軽に「動作する」などを口にすることはできません。私も一応開発者のはしくれなので。。。

 

---

わんくま同盟,Microsoft MVP for Visual C++(Oct 2005-) http://blogs.wankuma.com/tocchann/

Answer 8

スレッドの流れを折ってしまうと申し訳ないのですが、

　インストーラーは VC で独自に作られている

の部分に少々ひっかかります。

とっちゃんさんが最初に指摘されている通り、インストーラーが管理者権限で動いていなくて、設定情報などが VirtualStore にリダイレクトされてしまった、ということはないでしょうか？
私が経験したところだと、VB6 などのアプリが動かない場合によく見かけるのですが、自作のインストーラーだとインストーラーの自動検出に当てはまらなくなりがちです。
インストーラーを実行する時に管理者として実行すると上手くいったとか、エクスプローラーで「C:\Program Files」とかを開くとツールバーに「互換性ファイル」というメニューがあるとかいった場合ですと、リダイレクトされてしまった可能性が高いです。

　ユーザー アカウント制御 (UAC: User Account Control) - Windows 7 対応アプリケーションの互換性
　http://msdn.microsoft.com/ja-jp/windows/dd883236.aspx

　Windows Vista または Windows 7 のファイルおよびレジストリの仮想化に関する一般的な問題
　http://support.microsoft.com/kb/927387/ja

Answer 9

なので「バグです」とするのは何の問題もありません。「実際意図したとおりに動いていない(＝動作していない)」状態なのですよね？

はい。起動時にシステムエラーメッセージを出力して終了してしまいます。

とっちゃんさんの言いたいことは非常に良く分かります。私も開発者ですので自分の目で見て確認しないと気が済みませんから。。。

Answer 10

とっちゃんさんが最初に指摘されている通り、インストーラーが管理者権限で動いていなくて、設定情報などが VirtualStore にリダイレクトされてしまった、ということはないでしょうか？

VirtualStore にリダイレクトされてしまったことによって、C:\Program FilesではなくC:\Program Files(86)にインストールされてしまったということなのでしょうか？もしそうであれば、「C:\Program FilesとC:\Program Files(86)の両方にインストーラーでインストールしても動作しない」という現象は避けられそうにありませんが。。。

インストーラーを実行する時に管理者として実行するとうまくいったかどうかは確めていないのでなんともいえませんが。。。

Answer 11

VirtualStore にリダイレクトされてしまったことによって、C:\Program FilesではなくC:\Program Files(86)にインストールされてしまったということなのでしょうか？もしそうであれば、「C:\Program FilesとC:\Program Files(86)の両方にインストーラーでインストールしても動作しない」という現象は避けられそうにありませんが。。。

VirtualStore にリダイレクトされると、「C:\Program Files」でもなく「C:\Program Files (x86)」でもない、ユーザー専用の場所に保存されます。

　管理者権限での実行を制限するユーザー・アカウント制御UAC（後編） － ＠IT
　http://www.atmarkit.co.jp/fwin2k/vista_feature/08uac02/08uac02_02.html
　（「ファイルとレジストリの仮想化」あたり）

ですので、C:\Program Files 以下とか C:\Windows 以下に初期設定ファイルを作るようなアプリケーションで、
別のユーザーでログオンしている時に起動できない場合などは、このケースに当てはまっています。

ただ、64bit 環境で動かないはずのものを「Any CPU」で作ってしまっているとしたら、
x86 でモジュールを作り直すしかないと思います。

...PE ヘッダーを書き換えたら動くのかな...

　とあるコンサルタントのつぶやき : Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応
　http://blogs.msdn.com/nakama/archive/2008/11/06/part-2-net-framework-2-0-64.aspx

　CorFlags 変換ツール (CorFlags.exe)
　http://msdn.microsoft.com/ja-jp/library/ms164699.aspx

Answer 12

...PE ヘッダーを書き換えたら動くのかな...

技術的な可否はわかりません。
ただ、法的な問題として、著作権も考慮した上でバイナリを書き換える正当な権利を持っているのか、何らかの契約上の制約を受けないかも考慮すべきこととして、書き残しておきます。

# 考慮されているかもしれませんが、文面に出ていなかったので念のため書きました。ご了承ください。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。