I have a C#/WCF application (hosted in windows service) which was deployed and tested on 32 bit Windows server. Now I need to deploy it for production. My network team suggested to deploy it on 64 bit Windows Server to take full advantage of server capabilities.
My questions:
- Is there any performance gain in deploying an application on 64 bit OS? If yes, how much?
- Do I need to do any special to make my application 64 bit OS compatible? If yes, what?
P.S. My application is compiled with “Any CPU” option (Does it matter?).
There is blogs of information out there on this. A quick Bing will bring up 1000s of talking points: http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC But, to be brief:
Is there any performance gain on deploying an application on 64 bit OS? If yes, how much?
The most noticeable benefit is memory utilization – specifically, your service/app, and all of the server’s other services/applications, have more room to play. Only true if you have 4 GB or more of RAM. If you have less than that, you are actually wasting memory by each allocation of block.
The benefit, at the raw-performance level, is for every CPU cycle, you can execute up to 64bits of information, instead of 32bits – double the information. Significantly more noticeable with multi-threaded applications: e.g. Your WCF Service hosted in IIS, which is multi-threaded for the incoming requests. 🙂
Do I need to do any special to make my application 64 bit OS compatible? If yes, what?
Short answer, nothing what-so-ever. 🙂 And that’s the benefit of .NET, when you compile with the default “Any CPU” option!
When you compile code into assemblies, you are compiling code into an Intermediate Language (IL) – not actual machine code. The .NET CLR (Common Language Runtime) version, that is installed on the specific server/workstation/device that you are deploying to, is what takes your IL code and executes it in native instructions for that specific platform – x86, x64, or IA-64 (or AMD64, ARM, etc if there any tweaks utilized). You do not have to do anything!
As for coding practices, there is nothing specific to do either.
Referencing 3rd Party Native Assemblies?
Now, the only concern is if you are using referencing any 3rd-party assemblies through COM or alike that are compiled in native code (i.e. basically, 3rd party assemblies writting in raw languages). That becomes tricky referencing a 32-bit native assembly via a CLR on a x64 machine (basically, you have to force your application to complile to 32bit to access it). There are other work-arounds though, which is outside of the scope of this answer.
That’s why I either: stick to all .NET references, reference only 3rd party assemblies written in .NET, just write it myself, or beg the author of the 3rd party component to release both 32bit and 64bit compiled versions. The latter becomes difficult to test on your x86 (32bit) machine as you can only reference the 32bit versions, but will have to deploy the 64bit versions.
More-of-a-headache is when dealing with your own WCF project, and those 3rd-party native assemblies, is that the built-in WCF hosting service in Visual Studio (as well as Cassini) is only 32-bit, as well as Visual Studio’s IntelliSense. Yeah, it’s fun when using 3rd party native assemblies and trying to debug applications on a x64 machine. Good times!