64 Bit .Net Transition not entirely smooth
Having recently had the opportunity to get back into coding - and with a 64 bit machine no less – I found that migrating our company’s booking application from a 32 bit development environment to a 64 bit environment less than plain sailing. It seems that each dot net project compiled output can be marked as either any CPU, x86, 64 bit etc impacting how this is run inside of IIS7 on Vista 64 bit.
The challenge in our company application’s case being that some of the components shipped with it don’t come with 64 bit versions which causes some rather cryptic “BadImageFormat” type errors. In theory, recompiling the solution, but configuring the output for 32bit only instead of any CPU in the solution build properties should fix the problem – in our case however this turned out to be a bit of a problem due to a large number of sub projects with customized build output directories. Further confusing the matter was duplicate build outputs of different types in different directories because of a poor solution configuration by the former developers.
It turns out however there is an easy way to fudge this without changing the solution build output options within IIS7 – set the “enable 32 bit applications” option to true within the related web application pool in IIS 7. This runs the application in WOW64 bit mode and will at least get you up and running for development – in my view the jury is still out on running a 32 bit web application in WOW64 32 bit compatibility box.
Unfortunately that wasn’t the end of the story, some of the build output directories had hard coded references to sgen.exe in the post build event command line. Two problems here – Visual Studio 2008 doesn’t ship with this utility and you need to copy it from Visual Studio 2005/8 onto your machine unless you have upgraded – apparently the file was missed by Microsoft. The second issue is that on a 64 bit machine the default “c:\program files” becomes “c:\program files (x86)” so you need to use ($DevEnv) compiler variable instead of any hardcoding of directories to find sgen.exe . Probably something you should do anyway as it is pure folly to assume a fixed “c:\program…” directory structure in your build.
A bit of tweaking of the VMWare servers on the machine, firewall settings and the application ran. Although not a lot of documentation on the web currently on these issues so I suspect there aren’t many users of Visual Studio with large projects running on 64 bit development machines (as opposed to servers) as yet.
Tags: .Net Development, 64 bit development
Application Development | seand | 
April 28, 2009 3:45 am
Subscribe