Vista 64-bit Development Caveats

Question

I'm migrating my development workstation from 32-bit Vista to 64-bit Vista.

The production platform is 32-bit Windows Server and SQL Server 2008.

Does anyone know of any issues with migrating the code base?

EDIT:

the system consists of web forms, c# code, stored procedures.

there is also ajax.net, ssrs, ssis, and dynamic reports/graphs from dundas.

however, i think other users might appreciate any lessons learned or feedback in general regarding this move.

FINDINGS:

As of Jan 24, 2009

• Checkpoint VPN does not support Vista 64 (actually it seems that very few do)
• Cropper utility required special download and rebuild to work on Vista 64 (Cropper looks very nice, but it lacks scrollable window capture)

The lack of support for Vista 64 made it not worth while for me. I wish someone would have mentioned the lack of VPN support, but there is currently no vpn vendor that supports 64 bit clients.... So be forwarned - as of 1/28/2009 - using Vista 64 is not a good option for those of us who need vpn.

Answer 1

With regards to Vista x64 specifically, none come to mind other than generic 64bit porting considerations, such as never storing a pointer in an integer variable to prevent truncation of addresses, etc

Answer 2

I have come across one issue with Vista 64:

Program Files

Program files may be stored in Program Files x86 or in Program Files you may have to code around this if any of your code makes assumptions about where programs are stored - even if you have done the right thing and used environment variables, as there are 2 locations there are now 2 different environment variables. You need to know which of these your app will be installed in, which will be different if you target any CPU from if you target x86.

Answer 3

Don't use hard coded names for system folders.

(a bad idea anyway)

Answer 4

I had much trouble with adding 3rd party 32 bit ISAPI handler to IIS on 64 bit w2k3 server (php) I had to make IIS run in 32 bit compatibility mode. If it's all managed I can think of no serious problem though.

Answer 5

I have done exactly this - migrated my workstation to Vista 64 whilst still deploying code to 32-bit Win2008 servers.

Generally, your biggest problem will be the WOW64 emulation layer - which means that 32-bit processes and 64-bit processes see different versions of the same resources (registry keys, system folders, and so on.) In .NET, there's an enumeration System.Environment.SpecialFolder which will give you safely abstracted access to Program Files, Application Data and other potentially risky system folders. You'll also need to force IIS to run in 32-bit compatibility mode (it can't run 64-bit and 32-bit web apps simultaneously) - instructions at http://support.microsoft.com/kb/894435

There's nothing insurmountable, though - I'm successfully compiling COM-visible .NET assemblies on Vista x64 (setting the compiler to target x86 CPUs), and then deploying them alongside ASP.NET and legacy ASP code running 32-bit COM objects on a 32-bit server, and it's all working very well. There's some notes you might find useful posted on my blog; biggest headache I encountered personally was that 32-bit applications (including my favourite text editor) can't see C:\Windows\System32 any more... but even that's easy enough to work around.