我有一个在32位Windows服务器上部署和测试的C＃/ WCF应用程序（托管在Windows服务中）。现在我需要将其部署用于生产。我的网络团队建议将其部署在64位Windows Server上，以充分利用服务器功能。
我的问题：
P.S。我的应用程序是使用“任何CPU”选项编译的（这有关系吗？）。
答案 0 :(得分：1)
有关于此的信息博客。一个快速的Bing将带来1000个谈话要点：http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC但是，简而言之：
在64位操作系统上部署应用程序是否有任何性能提升？如果是，多少钱？
最明显的好处是内存利用率 - 特别是您的服务/应用程序，以及所有服务器的其他服务/应用程序，都有更多的发挥空间。仅当您有4 GB或更多RAM时才为真。如果你的数量少于那个，你实际上是在每次分配块时浪费内存。
原始性能级别的好处是每个CPU周期，可以执行高达64位的信息，而不是32位 - 信息的两倍。多线程应用程序显着更明显：例如您的WCF服务托管在IIS中，它是传入请求的多线程。 ：）
我是否需要做任何特殊工作才能使我的应用程序与64位操作系统兼容？如果是，那该怎么办？
简短的回答，没有什么比这更好的了。 :)当您使用默认“任何CPU”选项进行编译时，这就是.NET的好处！
将代码编译到程序集中时，您将代码编译为中间语言（IL） - 而不是实际的机器代码。 .NET CLR（公共语言运行时）版本安装在您要部署到的特定服务器/工作站/设备上，它是您的IL代码并在该特定平台的本机指令中执行它 - x86，x64或IA-64（或AMD64，ARM等，如果使用任何调整）。你不需要做任何事情！
至于编码实践，没有具体的做法。
引用第三方原生程序集？ 现在，唯一的问题是，如果您使用通过COM引用任何第三方程序集，或者使用本机代码编译的类似程序（即基本上是以原始语言编写的第三方程序集）。通过x64机器上的CLR引用32位本机程序集变得棘手（基本上，你必须强制你的应用程序压缩到32位才能访问它）。还有其他解决方法，这超出了本答案的范围。
这就是为什么我要么：坚持所有.NET引用，仅引用用.NET编写的第三方程序集，只是自己编写，或者请求第三方组件的作者发布32位和64位编译版本。后者变得难以在您的x86（32位）机器上进行测试，因为您只能引用32位版本，但必须部署64位版本。
在处理您自己的WCF项目和那些第三方本机程序集时，更令人头疼的是，Visual Studio（以及Cassini）中的内置WCF托管服务仅为32位，以及Visual Studio的IntelliSense。是的，使用第三方本机程序集并尝试在x64计算机上调试应用程序时很有趣。好时光！