私のアプリケーションは x64 アプリケーションとして構築されています。VS2010 に移行した後、参照されている dll の x64/x86 の不一致に関連していると思われる問題がいくつか発生しました。現在、.NET4 をターゲットにしていますが、同様の問題がさらに発生します。
私の質問は次のとおりです。x64 と x86 を混在させる場合、どのような予防措置を講じる必要がありますか。それはまったくできますか？x64 アプリケーションは x86 dll を問題なく使用できるはずだと思いました。いいえ？他の方法はどうですか？x86 アプリケーションは、x64 プラットフォームで実行されている限り、x64 dll を参照できますか? 知っておくべき落とし穴は何ですか?
いいえ、64 ビット プロセスは 64 ビット DLL のみをロードでき、32 ビット プロセスは 32 ビット DLL のみをロードできます。おそらく考えているのは、64 ビットのオペレーティング システムは 32 ビットのプロセスを実行できるということです。
.NET の主な問題は、VS2010 以前では、実行可能プロジェクトがデフォルトで「AnyCPU」に設定されていたことです。これは、実行中の OS の「ネイティブ」形式で読み込まれることを意味します (つまり、32 ビット バージョンの Windows の場合は 32 ビットであり、 64 ビット バージョンの Windows の場合は 64 ビット)。これに関する問題は、アプリケーションを 32 ビット Windows (たとえば) でテストした場合、32 ビット DLL をロードして 64 ビット Windows で実行しようとすると、アプリケーションが壊れる可能性があることです。
VS2010 では、すべての実行可能プロジェクトを既定で "x86" (つまり、32 ビット) に設定し、(ほとんどの場合) 問題を軽減します。
WOW32エミュレーションを使用して、64ビットOSでx86アプリを実行できます。私が遭遇したいくつかの落とし穴-同じプロセスで32/64を組み合わせることができません。したがって、IISを64として実行する場合は、すべてのアセンブリを64にする必要があります。そうでない場合は、32ビットモードで実行する必要があります。64ビットは、一部のアプリを他のアプリよりも役立ちます。SQLサーバーの64ビットバージョンを実行すると、32ビットバージョンに比べていくつかの利点があります。最大の利点は、ターゲットサーバーに4 GBを超えるメモリをインストールでき、SQLが4GBを超えるメモリを使用できることです。IISは通常3GBを超えるメモリを使用できないため、IISにはそれほどメリットはありません。私のアドバイスは、可能であればSQL server / os/versionが64であることを確認することです。それは作るつもりはありません。他のサーバーが64の場合、大きな違いがありますが、通常は