VisualStudioのフォームビューで発生するエラーの対応方法について教えてください

Question

現在、過去に開発した32bit資産を64bitに変換しようとしてます。

一部のユーザコントロールを32bitで組み込みたいのです。

そこで、「Debug」時にプラットフォームを「AnyCPU」とし、

配布用には「Release」は「X64」を採用しています。

※修正作業を32bitで行い、リリース時に64bitビルドすることが妥当な方法であるか確認したい。

（問題なくアプリケーションは動作するのですが、問題ないのでしょうか）

Answer 1

表題（エラーの対応方法）と質問内容（動作するけど問題ないか）が違うような気がするのですが？

質問の内容も意味が分かりません。「過去に開発した32bit資産」とは具体的に何なのですか？

一度、以下の記事を読んで、32/64-bit 動作の基本的な知識、コンパイルオプションの設定の知識を得て、それから考えた方がよさそうな気がします。

Part 1. 64 ビット Windows OS の基本知識
https://blogs.msdn.microsoft.com/nakama/2008/10/30/part-1-64-windows-os/

Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応
https://blogs.msdn.microsoft.com/nakama/2008/11/05/part-2-net-framework-2-0-64/

VS2012のC#プロジェクトのプラットフォーム構成(Any CPU・32ビットの優先)
http://sourcechord.hatenablog.com/entry/20130412/1365789867

Answer 2

Visual Studio の Windows Forms のデザイナは、Visual Studio のプロセス内でコードを実行する形で画面を表示する仕様となっています。
そのため、ユーザーコントロールが含まれるアセンブリが x86(32bit) で読み込める形になっている必要があります。

極端な話、x86/x64 のどちらで実行されるかを決定するのは、exe プロジェクトだけなので、exe プロジェクトだけ x64 とし、その他のプロジェクトを Any CPU で作り込み、exe プロジェクトは Program.cs だけにすれば、問題の多くは片付きます。
それが難しい場合、UI プロジェクト（View プロジェクト）だけは Any CPU にできるように設計・実装することで問題を回避できます。

さて、ご質問の修正を 32bit で実施し、リリースを 64bit で実施することが妥当かについてですが、デザインの観点だけであればおおよそ問題は起きないと思いますが、実行時に崩れるかどうかはそのコード次第ですので、第三者にはコメントできない話です。
ユーザーコントロールやそれにまつわるクラス群が、32bit と 64bit で動きが変わらないのであれば、問題はないでしょう。

// ところで、32bit と 64bit は混ぜられないという前提はご存知の上の話だと思っていますが、相違ないですよね？
// ユーザーコントロールが x86 指定でビルドされていたら、どんな方法であろうと、64bit プロセスでは読み込めませんので。

Answer 3

Azulean さんのレスを読んで表題（エラーの対応方法）と質問内容（動作するけど問題ないか）がやっとつながりました。

表題：「過去に開発した32bit資産」というのは x86 でコンパイルしたカスタムコントロール。それを x64 でコンパイルし直して、それを Visual Studio 上でアプリに配置しようとすると Visual Stuio は 32-bit なのでエラーが出る。なので、コントロールのプロパティの設定などができず、開発に支障を生じている。

質問内容：それゆえ、開発時はカスタムコントロールは Any CPU でコンパイルし、Visual Studio でアプリに配置してプロパティなどの設定を行う。リリース時に x64 でコンパイルし直す。← これが問題ないかというのが質問内容。

・・・という理解でいいのでしょうか？＞質問者さん

であれば、ホントに x64 でコンパイルする必要があるか、先に紹介した記事を読んで考え直した方がよさそうな気がします。

x64 でコンパイルすると 64-bit OS でしか動かなくなり、まだまだ巷には多くあると思われる 32-bit OS で使えなくなります。（上に紹介した「Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応」の Step 8 の中の一番下の図を見てください）

目的が単に 64-bit OS に対応するということであれば以下の対応がよさそうです。

(1) x86 でコンパイルしたカスタムコントロールには手を加えない。それを利用するアプリは x86 でコンパイルする。32-bit OS では当然問題なく動くし、64-bit OS では WOW 上で動くのでやはり問題ないはず。（上に紹介した「Part 2. .NET Framework 2.0 アプリケーションの 64 ビット対応」の Step 9 の中の一番下の図の「例4.」参照）

(2) すべて Any CPU でコンパイルする。（Step 9 の中の一番下の図の「例1.」参照）

上記のいずれかの対応をお勧めします。

Answer 4

科学技術演算結果が異なる場合があります。

http://stackoverflow.com/questions/4018895/why-does-math-exp-give-different-results-between-32-bit-and-64-bit-with-same-in

http://stackoverflow.com/questions/2461319/c-sharp-inconsistent-math-operation-result-on-32-bit-and-64-bit

http://stackoverflow.com/questions/2342396/why-does-this-floating-point-calculation-give-different-results-on-different-mach/2343351#2343351

コンパイル条件や演算途中の丸め処理の有無などで結果は異なりますが、過去に演算した同じ計算、他のPCで演算した同じ計算の結果が一定の誤差範囲内で一致していることが要求される場合には問題になります。

勿論、64bit JITの変更の影響も受けるかもしれません。

Answer 5

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

先に、SurferOnWwwからご注意受けましたが、拙い質問をご理解いただきありがとうございました。

Answer 6

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

拙い質問分で申し訳ありませんでした。SurferOnWwwさんが記載していただいた内容で間違いありません。

先の、Azuleanさんの回答、本回答の内容を参考に、考えなおします。

Answer 7

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

精度の高い計算には使っていませんので、問題ありません。