要在64位操作系统上运行,我需要对我的WCF应用程序做哪些更改?

在这上面有很多信息博客。一个快速的必应将带来1000多个谈话要点: http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC 但简而言之:

在64位操作系统上部署应用程序是否会获得性能提升?如果是,多少钱?

最显著的好处是内存利用率——特别是,您的服务/应用程序以及服务器的所有其他服务/应用程序都有更多的空间可供使用。只有当您有4GB或更多的RAM时才是这样。如果您的内存小于这个值,那么实际上是在每个块分配过程中浪费内存。

在原始性能级别上,好处在于,对于每个CPU周期, 可以 执行高达64位的信息,而不是32位-使信息加倍。对于多线程应用程序来说,更值得注意的是:例如,您的WCF服务托管在IIS中,它对传入的请求是多线程的。:)

为了使我的应用程序与64位操作系统兼容,我需要做什么特殊的事情吗?如果是,什么?

简短的回答,什么都没有。:)这就是.NET的好处,当您使用 违约 “任意CPU”选项!

当您将代码编译成程序集时,您将代码编译成中间语言(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计算机上调试应用程序时很有趣。好时光!