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?
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.
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.
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.
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
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
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!
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.
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.
TFS does not support 64 bits (TFS Server, not sure for team explorer)
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.”
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.
We ran into 2 different types of problem:
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.
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.