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

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 2

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 3

It depends.

Have you used P/Invoke in your code?

Have you used unmanaged code and marshalled data to and from it? If so then you will have to go through this code with a fine tooth comb :(.

However if your code is pure C# which hasn't used P/Invoke then the only difference you should see is a slight performance increase and better memory performance :).

You may however run into gremlins finding drivers for your development machines.

If you have some 32bit code then perhaps you could create a WCF interface to it (named pipes are very, very fast) and use that to talk to a 32bit service. I know that you can't have 32bit code in a 64bit process, but I think you can open a pipe to a 32bit process, unless I have that wrong. You could always use TCP/IP in that case. Might save you from rewriting critical code in your system and allow you to use WOW64 or a VM to deal with a migration issue.

Answer 4

We ran into 2 different types of problem:

1. We had a 3rd party component that wrappered a native 32-bit dll. The vendor did not offer a 64-bit version, so we had to target 32-bit development.

2. A few driver problems. XP-64 hadn't caught on a whole lot (has it now?) when we tried it. The problems weren't related to development, but we had some trouble with printer drivers, network drivers, etc). In vista, they changed the driver model, so there may be more 64-bit drivers out there now, but I don't know whether they will be backwards compatible with XP.

Answer 5

TFS does not support 64 bits (TFS Server, not sure for team explorer)

Answer 6

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.