Are there any considerations needed to be taken running your .net program on x64 vs x86?

Question

I believe the architecture type (x86 vs x64) is abstracted away for you when making .Net programs, but are there any other considerations that can cause problems?

Answer 1

Beware of third-party COM libraries or third party .NET libraries that secretly make win32 calls. That's where we had our biggest headaches.

Answer 2

x64 will allow you to address more memory, but given the same code, it will use more memory than x86.

Answer 3

From the MSDN doco, among other considerations:

In many cases, assemblies will run the same on the 32-bit or 64-bit CLR. Some reasons for a program to behave differently when run by the 64-bit CLR include:

• Structs that contain members that change size depending on the platform, such as any pointer type.

• Pointer arithmetic that includes constant sizes.

• Incorrect platform invoke or COM declarations that use Int32 for handles instead of IntPtr.

• Casting IntPtr to Int32

Answer 4

This article has a lot of good issues to be aware of: http://osnews.com/story/20330/Windows_x64_Watch_List

Personally, my boss has a 64-bit Vista computer, and I program in a 32-bit mode. We've run into the following issues:

• Registry for 32 bit apps gets hidden (sort of) into a Wow6432Node folder. Not all apps you are used to finding a path for in the registry will be in that node (SQL Server won't, for instance).

• SysWow64 in the C:\Windows folder can cause issues of DLLs not being where they are needed (we had this issue w/ a 3rd party licensing component).

• Sometimes the files you need are in "C:\Program Files (x86)", rather than "C:\Program Files". Sucks too.

Answer 5

• Reading and writing to 64 bit values is not thread safe on a 32 bit platform. Reading a 64 bit value takes two operations which could be interrupted by a context switch. See the MSDN article on Threading.Interlocked.Read for more information.

• Also agree entirely with torial's answers! :-)

Answer 6

MSDN had put up a little paper regarding issues of porting 32-bit applications over to 64-bit execution environment.

http://msdn.microsoft.com/en-us/library/ms973190.aspx

Two other bloggers had previously wrote about 64-bit development when they were working in the CLR team

• Gaurav Seth
• SpankyJ

Answer 7

In my experience porting an Asp.NET application was basically flawless. Run on 32 bit machine and on 64 bit and no problem happens, beside having more memory available. This happens because a lot of the issues already mentioned (registry, threading and so on) have been managed by Asp.NET and you need to properly fix them to run in the Asp.NET environment.

Client side (windows form) the same happened but it if you've used some "unsafe" APIs to get special folders or registry access then some problem can happen, as already pointed.

Regards Massimo