misc.log

日常茶飯事とお仕事と

開発するアプリのコンパイルターゲットCPUをどう設定すべきかねぇ…

お仕事で迷うことがあったので、しらべて通知したお話を可能な範囲で転記しておきましょう。

開発チーム向け回答抜粋

実装〜結合テスト工程では以下の設定とします

  • 32bitクライアント用アプリケーション: x86
  • 64bitサーバー用アプリケーション、共通DLL : AnyCPU


ただし、テストの過程で変更する可能性がありますので、プラットフォーム依存と思われる問題が出た場合は上記設定が原因である可能性も視野に入れた調査と対応をお願いします。

■補足
ここの方針は将来変わる可能性があります。あくまで現時点の工程における措置と考えてください。可能性としてはサーバーもクライアントもx86でコンパイルすべき、という決定になるかもしれません。AnyCPU設定は「64bit環境、32bit環境どちらも用意してその場で切り替える」的アプローチらしいので、そもそもx64指定でサーバー上で動かない場合はAnyCPUでもダメです。その場合は、すべてx86にして、サーバー上のアプリはWOW64モード(←検索してください)で動かすという選択肢になるかと思います。


参考までに、以下のような情報があります。

AnyCPU Exes are usually more trouble than they're worth
http://blogs.msdn.com/b/rmbyers/archive/2009/06/8/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx
.NETから統合アーカイバ仕様DLLを呼び出すなら、x86でビルドしよう
http://d.hatena.ne.jp/Wacky/20110503/1304434327
EXE を作るプロジェクトのデフォルトが Any CPU から x86 に変わった理由 - または Any CPU の本当の意味
http://d.hatena.ne.jp/siokoshou/20091102/p1


完全に.NETの機能だけで作られたものであれば、リリースされるアセンブリは中間言語で記載されており、実行時に対象CPUに合わせてその場でコンパイルされながら動きます。ですが、WindowsAPIを直接呼んでいたり、.NETの管理下にない処理を行っていたりするとそうも行きません。平たく言うなら、Windows\System32フォルダ(いわゆる)をみる処理があった時点で、トラブル発生の可能性が出てきます。詳しい話は上記ブログなどを読んで確認願います。


結局のところ、サーバーアプリについては64ビット環境で実際に動かしてみて、どうすべきかを決める必要があります。少なくとも、32ビット環境(開発環境)で動いたからOK、とは言えなさそうです。


場当たり的な対応になりますが、今回、サーバー環境が64ビットであるということを記憶の片隅に留めておいて、何か問題が出た場合はそのあたりからの調査と必要であれば設定変更の提案をお願いします。