Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?

Question

My team is getting new XP64 workstations. We\'ve been using XP32 up until now. Most of our work is done in managed C#/VS2008/.net 3.5 and SQL Server 2005. However we do have

Answer 1

I've been developing on 64-bit platform for some time. This is a small tip that can save you a headache.

If you get the exception

"BadImageFormatException" (e.g. "Could not load or assembly 'Microsoft.TeamFoundation etc etc or one of its dependencies. An attempt was made to load a program with an incorrect format")

there is a high probability that the application could not find a 64 bit version of the assembly.

We experience this error frequently when accessing databases using OLEDB/Jet drivers. I've also experienced this with tools that integrate with TFS.

To fix this, head to the "Compile" tab under your project settings, "Advanced Compile Options" and select "x86" as the target CPU.

Hope this helps!

Answer 2

I have used XP 64 bit for a few months last year. My experience was that the Microsoft development stack installed and worked without any issues, including a 64-bit version of SQL Server.

I ran into problems with the network drivers for the onboard Marvell Yukon network card of my Asus board. The 64 bit drivers had serious issues that were not immediately obvious, but became apparent after several months of intense testing. Network transfer rates on a Gigabit network were not as expected, and when two processes accessed the same network resource, Windows would crash.

My recommendation is, just like the other poster suggested, to test the hardware-software setup before you switch over the entire team. This is more likely where you will see issues.

Answer 3

There will be two sets of ODBC Data sources (DSN) now: 32-bit and 64-bit. Some databases don't currently have updated drivers for 64-bit, so you will be forced to use the 32-bit drivers or you can just wait.

Answer 4

Sun has a good article about it. http://developers.sun.com/solaris/articles/ILP32toLP64Issues.html

It is not unusual for current 32-bit applications to assume that the int type, long type, and pointers are the same size. Because the size of long and pointer change in the LP64 data model, this change alone is the principal cause of ILP32-to-LP64 conversion problems.

Answer 5

If you are referencing any third party DLLs that are compiled for 32-bit, then you will have to target your applications for 32-bit. This can be done by either changing the project settings or using the corflags application with the /32BIT+ parameter.

The only "gotcha" that I have encountered in my many months of XP x64 as a development workstation is that Edit-And-Continue does not work in the Visual Studio debugger in 64-bit applications.

Answer 6

You may run-in to an issue with string.GetHashCode() returning a different value for the same string on 32-bit and 64-bit machines as they'll run different versions of the CLR.

Crucially:

“The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode.”

More info here and here.