VS2012 (および以前のバージョン...) では、プロジェクトをビルドするときにターゲット プラットフォームを指定できます。ただし、私の理解では、C# は CIL に「コンパイル」され、ホスト システムでの実行時に JIT コンパイルされます。
これは、ターゲット プラットフォームを指定する唯一の理由は、ユーザーが特定のアーキテクチャでソフトウェアを実行することを意図的に制限すること、またはアプリケーションを 64 ビット マシンで 32 ビットとして実行することを強制することであるということですか? ホスト アーキテクチャでジャスト イン タイムが発生する CIL --> ネイティブ ステージで発生すると推測するため、最適化に関係しているとは思えません。
この MS リンクは代替の説明を提供していないようであり、たとえば、同じアプリケーションの個別の 32/64 ビット バージョンをリリースする必要があるという事実の示唆を見つけることができません。最適化は JIT 段階で適用されます。
これは、ターゲット プラットフォームを指定する唯一の理由は、ユーザーが特定のアーキテクチャでソフトウェアを実行することを意図的に制限すること、またはアプリケーションを 64 ビット マシンで 32 ビットとして実行することを強制することであるということですか?
はい。これは、マネージド コードとネイティブ コードを混在させて使用している場合に重要です。ただし、実行時に最適化されるものは変わりません。
コードが 100% 管理されている場合は、AnyCPU (または新しい AnyCPU Prefer 32-Bit) で問題ない可能性があります。コンパイラの最適化は同じであり、JIT は現在実行中のプラットフォームに基づいて実行時に最適化されます。
たとえば、同じアプリケーションの別々の 32 ビット バージョンと 64 ビット バージョンをリリースする必要があるという事実についての提案は見つかりません。
非マネージ コードとの相互運用を実行している場合を除き、これを行う理由はありません。その場合、個別の 32 ビット DLL と 64 ビット DLL が必要になります。
リードはここで良い答えを持っています。ただし、この設定はDLLの単なるフラグであり、ほとんどの状況ではほとんど効果がないことを指摘することも重要だと思います。このフラグを確認し、適切なバージョンの.NETランタイムを起動するように指示するのは、ランタイムローダー（.NETランタイムを開始するネイティブコードのビット）の責任です。
このため、フラグはほとんどの場合、EXEファイルに設定されている場合にのみ問題になり、DLLに設定されている場合は効果がありません。たとえば、64ビットフラグの.NETEXEまたは任意のCPUフラグの.NETEXEのいずれかで使用される「32ビットフラグの.NETDLL」があり、EXEを64ビットマシン-その後、ローダーは64ビットランタイムを開始します。32ビットDLLをロードするときは、手遅れです。64ビットランタイムがすでに選択されているため、プログラムは失敗します（受け取るのはBadImageFormatExceptionだと思います）。