2012-03-02 19 views
1

Windows XP 32ビット開発マシンを使用して、Visual Studio 2005、Framework 2.0で作成されたアプリケーションを維持します。開発環境を64ビットに変更するWindows 7 - アプリケーションがクラッシュする

私の新しい開発機はWindows 7 64ビットです。

ソリューションをVisual Studio 2010に読み込み、すべてのプロジェクト(実際のアプリケーションで使用されているものがいくつかあります)を正常に変換し、Framework 4.0に更新しました。

デバッグモードでは、アプリケーションは問題なく実行されます。

ここでは、これまでのインストーラーは1つしかインストールされていないということがあります。変更はサーバーに展開されます。インストール後にアプリケーションを実行すると、実際にアップデータアプリを実行してサーバとファイルの変更を確認し、見つかった場合はダウンロードしてクライアントの元のファイルを置き換えてから「本当の」アプリケーションを走る

64ビットマシンでコンパイルした最初のバージョンをサーバーにインストールした後、インストールされたバージョンのアプリケーションを実行して正常に動作するかどうかをテストしました。アップデーターは正常に動作するように見えましたが、「本当の」アプリを起動するとクラッシュします。 ProviderDesktop.exe、バージョン:2.6.0.0、タイムスタンプ:モジュール名をフォールティング0x4f4fad5e :KERNELBASE.dll、バージョン:6.1.7600.16850、アプリケーション名をフォールティング

のWindows 7上のファイル名を指定して実行、それがでクラッシュタイムスタンプ:0x4e211485 例外コード:0xe0434352 障害オフセット:0x0000b9bc 断層のプロセスID:0x2388 エラー発生アプリケーションの開始時刻:0x01ccf8971407b4fe アプリケーションパスをフォールティングします。C:\ Program Files(x86の)\ UHINt2.5 \ ProviderDesktop.exe 断層をモジュールパス:C:\ Windows \ syswow64 \ KERNELBASE.dll レポートID:53717437-64

イベントタイプ:clr20r3のP1:providerdesktop.exeのP2:2.6.1.1
P3:4f4fad5e P4:providerdesktopのP5:2.6.1.1 P6 XP上の8A-11E1-a455-8a2e36aa00e8

実行し、それがでクラッシュ:4f4fad5e
P7:85d P8:0 P9:system.io.fileloadexception

これまでに2つの診断が行われました。

まず、Fusionロギングを試しました。何も見つかりませんでした。

第2に、私はWindows 7開発マシン上の欠陥のあるアプリケーションを読み込むDependencyWalkerを試しました。 IESHIMS.DLLがありませんでした。 thisの記事を参照すると、私はIESHIMS.DLLを見つけましたが、DependencyWalkerでは実際にDLLがアプリケーションのルートフォルダにあることが予想されていました。私はそこに置き、DependencyWalkerを再実行し、そのエラーはなくなった。しかし、別のエラーがあります。私は強く、この問題の根本的な原因と思われます。エラー:異なるCPUタイプのモジュールが見つかりました。

ieshims.dllと私の実際の.exe(x86)を除いて、DependencyWalkerにリストされているすべてのモジュールはx64です。 UpdaterとRealの両方のアプリはx86プラットフォームをターゲットにしています。

一部の同僚は、私がReal Appのサードパーティの参照のために問題があるかもしれないことを示唆していました。私がここで見ることができて、それはそうではないようです。

誰かが私にこれを手伝ってもらえると、私は本当にx86/x64のような低レベルの概念についてあまり知りませんので、私は間違いなく感謝します。これは、2010/.NET 4.0のすばらしい高速マシンで開発することと、重大なパフォーマンスの問題があり、2005/.NET 2.0で開発するこのアプリケーションのために、VMをXP/32の周りに保つこととの違いを意味します。

私の目標は、Win7x64、2010、4.0上でアプリケーションを開発し、アップデーターのクライアントのバージョンの問題を起こさずにアプリケーションを更新できるようにすることです。

事前に感謝します。

答えて

0

32ビットと64ビットを明示的にターゲットにしたアセンブリを混在させることはありませんでした。

すべてのターゲットを任意のCPUに変更しようとしましたか?

0

安全でないコードが含まれていない場合、.Netは64ビットマシンで完全に動作します。安全でないコードのほとんどは、ネイティブの64ビットモードで動作するように修正する必要があります。

しかし、アプリケーションがWOW(WindowsのWindows)モードで動作するように要求することができます。この場合、アプリケーションは32ビットマシンとまったく同じように動作します。これはプロジェクトプロパティで有効になり、プラットフォームターゲットを任意のCPUではなくx86に設定します。

関連する問題