Team is Going from XP32 to XP64 for .NET Developme

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 a couple apps that are still in VS2005/.net 2.0. The majority of our applications are ASP.NET webforms apps and WCF services that are running on 64bit servers in production. However, we have some WPF development going on that will have to run on 32bit machines.

Are there any gotchas or transition pains we should be aware of?

Answer 1

You won't be able to talk to MS Access databases from .NET x64, because there are no x64 Jet drivers.

I would consider this an excellent reason to move to x64.

Answer 2

hope this help

Registering COM 32 bit DLL for asp 64 bit call

Many links about convention 32-64 bits

General FAQs About 64-bit Windows

64-bit System Design

see this tips too Biggest performance improvement you’ve had with the smallest change?

more great blog tips : Back to Basics: 32-bit and 64-bit confusion around x86 and x64 and the .NET Framework and CLR

Windows Application Quality Cookbook from Microsoft

DevReadiness.org
This site is dedicated to assisting the Windows ISV ecosystem develop high quality applications for new versions of the platform. Windows 7 was recently announced at the PDC 2008 conference, a link to the new app readiness "cookbook" is provided on the right

The Microsoft.com OPS guys have blogged about their migration to x64 and how it all works.
Running Microsoft.com on 64 Bit…The Dependencies, The Goodness, the Gotcha’s

Answer 3

• Mixed-Mode debugging is an issue if you use any C++ and C# with 64-bit applications.
• There are still many development tools that don't support running on Windows x64 or don't support working with 64-bit binaries. Take for instance, Compuware DevPartner. It currently only supports 32-bit application development, but the application itself will run on 64-bit Windows.

Answer 4

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.

Answer 5

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 6

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.