私はWPFexeをデプロイしましたが、フィールドでは実際にx86として実行されているので、WOW64が原因でAnyCPUに設定されたときに人々が言及した奇妙な動作に遭遇しないことを確信できます。私のプロジェクト(32ビットdllに依存していますが、プロジェクト内のアセンブリのみ)の設定は次のとおりです。
しかし、私のソリューション構成はAnyCPUに設定されています。
私のアプリが32ビットであるとまだ確信できますか?
ああ、これが私のコフラッグです。
私はWPFexeをデプロイしましたが、フィールドでは実際にx86として実行されているので、WOW64が原因でAnyCPUに設定されたときに人々が言及した奇妙な動作に遭遇しないことを確信できます。私のプロジェクト(32ビットdllに依存していますが、プロジェクト内のアセンブリのみ)の設定は次のとおりです。
しかし、私のソリューション構成はAnyCPUに設定されています。
私のアプリが32ビットであるとまだ確信できますか?
ああ、これが私のコフラッグです。
これはVS2010の設計上の欠陥であり、以前のバージョンのVSからプロジェクトを変換したときに特に発生します。プラットフォーム名は、最終プロセスのビット数にはまったく影響しません。これは単なる名前であり、管理対象プロジェクトのプロジェクト設定に直接影響することはありません。
プロジェクト+プロパティ、ビルド、「プラットフォームターゲット」の設定のみが重要です。さらに、EXEプロジェクトの設定のみが重要であり、DLLは、EXEプロジェクトの起動時に選択されたビット数に応じて動作する必要があります。したがって、DLLプロジェクトの通常の設定はAnyCPUです。また、プロセスを32ビットにする場合は、EXEプロジェクトの設定をx86に変更します。プラットフォーム名を一致させたい場合は、「x86」という名前の別の名前を追加します。これは、VS2010で新しいプロジェクトを作成するときのデフォルト名でもあります。プラットフォーム名をC#プラットフォームのターゲット設定と一致させるかどうかはあなた次第であり、自動ではありません。リリース構成の設定も変更することを忘れないでください。
プラットフォーム名は、ネイティブプロジェクト、特にC++プロジェクトにとって重要になります。AnyCPUのようなものはサポートされていないため、個別のビルドが必要です。プラットフォームセレクターは、ビルドを簡単に切り替えるのに便利です。