32ビットWindowsサーバーにデプロイおよびテストされたC#/WCFアプリケーション(Windowsサービスでホスト)があります。次に、本番用にデプロイする必要があります。私のネットワーク チームは、サーバー機能を最大限に活用するために、64 ビット Windows Server に展開することを提案しました。
私の質問:
PS 私のアプリケーションは、「任意の CPU」オプションでコンパイルされています (関係ありますか?)。
これに関する情報のブログがあります。簡単なBingは、何千もの論点をもたらします。http: //www.bing.com/search? q=x64+vs+x86+server&src= IE-SearchBox&FORM =IE8SRC しかし、簡単に言うと、
64ビットOSにアプリケーションをデプロイすることでパフォーマンスが向上しますか？はいの場合、いくらですか？
最も顕著な利点はメモリ使用率です。具体的には、サービス/アプリ、およびサーバーの他のすべてのサービス/アプリケーションには、より多くのプレイスペースがあります。4GB以上のRAMがある場合にのみ当てはまります。それより少ない場合は、ブロックの割り当てごとに実際にメモリを浪費しています。
生のパフォーマンスレベルでの利点は、CPUサイクルごとに、 32ビットではなく最大64ビットの情報を実行できることです。情報は2倍になります。マルチスレッドアプリケーションで大幅に目立ちます。たとえば、IISでホストされているWCFサービスは、着信要求に対してマルチスレッド化されています。:)
アプリケーションを64ビットOS互換にするために特別なことをする必要がありますか？はいの場合、何ですか？
簡単な答え、何もありません。:)これは、デフォルトの「任意のCPU」オプション を使用してコンパイルする場合の.NETの利点です。
コードをアセンブリにコンパイルすると、実際のマシンコードではなく、中間言語（IL）にコードがコンパイルされます。デプロイ先の特定のサーバー/ワークステーション/デバイスにインストールされている.NETCLR（共通言語ランタイム）バージョンは、ILコードを取得し、その特定のプラットフォーム（x86、x64、またはIA-64（または、調整が利用されている場合はAMD64、ARMなど）。何もする必要はありません！
コーディングの慣行に関しては、どちらかを行うための特別なことは何もありません。
サードパーティのネイティブアセンブリを参照していますか？ さて、唯一の懸念は、ネイティブコードでコンパイルされたCOMなどを介してサードパーティのアセンブリを参照することを使用しているかどうかです（つまり、基本的に、生の言語で記述されたサードパーティのアセンブリ）。これは、x64マシン上のCLRを介して32ビットネイティブアセンブリを参照するのが難しいことになります（基本的に、アプリケーションにアクセスするには、アプリケーションを32ビットに準拠させる必要があります）。ただし、この回答の範囲外である他の回避策があります。
そのため、私はすべての.NET参照に固執するか、.NETで記述されたサードパーティアセンブリのみを参照するか、自分で作成するか、サードパーティコンポーネントの作成者に32ビットと64ビットの両方のコンパイル済みバージョンをリリースするよう依頼します。後者は、32ビットバージョンしか参照できないため、x86（32ビット）マシンでのテストが困難になりますが、64ビットバージョンを展開する必要があります。
さらに厄介なのは、独自のWCFプロジェクトを処理する場合であり、それらのサードパーティのネイティブアセンブリは、Visual Studio（およびCassini）に組み込まれているWCFホスティングサービスも32ビットしかないことです。 VisualStudioのIntelliSenseとして。ええ、サードパーティのネイティブアセンブリを使用して、x64マシンでアプリケーションをデバッグしようとすると楽しいです。良い時代です！