I’ve bitten the bullet and decided to run Windows Server 2008 Hyper-V on my workstation; in addition to virtualising my MOSS dev environment, I’ve also chosen to virtualise my workstation environment on Windows Server 2008 x64; work won’t let me get away with Windows 7 RC1 and there’s no “supported” upgrade path to the RTM anyway.
You may have read my previous post on the subject of x64 targeting with Visual Studio setup projects; today, however, is all about just getting VS to compile a project with a post-build event where Visual Studio 2008 is running on Windows Server 2008 x64 with SP2. In our case, the post-build event needs to run sgen.exe from the correct location since some of our devs are still on Vista x32. And yeah, I know, post-build events are old school but it’s an existing solution…
Windows Server 2008 with Visual Studio 2008 SP1 and .NET 3.5 SP1 installed does not include sgen.exe for some reason. Why not?!? Good question—you can install it by downloading the Windows SDK for Windows Server 2008 and .NET Framework 3.5. v6.0a does seem to be installed by VS2008 on 32-bit/W2k3 environments (more about this). Kicking off the SDK installer, I chose to install the .NET Development Tools only (Developer Tools\Windows Development Tools\.NET Development Tools).
This all seems good but sgen will be installed to a different location than you may be used to: %programfiles%\Microsoft SDKs\Windows\v6.1\Bin\x64 (the 64-bit Program Files folder, that is). To accommodate this difference from the 32-bit world, I need some conditional logic in my post-build event.
At first glance, using the %processor_architecture% environment variable makes sense—it returns “x86” in my current XP 32-bit environment, presumably the same in Vista x32, and “AMD64” in Hyper-V… not quite “x64” but enough to branch on. As we all know, however, Visual Studio is only available as a 32-bit application and seems to do some additional environment variable setting of is own: echo %processor_architecture% in a post-build event prints out “x86”, obviously the same as our 32-bit environment. No good.
To work around and take advantage of this, my post-build event compares the %ProgramFiles% variable against “C:\Program Files”; when queried from a post-build event in a 64-bit environment, it reliably returns “C:\Program Files (x86)” which I know is the 32-bit Program Files folder; in that case, my script uses the 64-bit sgen. Note the same variable will return “C:\Program Files” in a normal command window so be careful and test in VS directly.
In the end, here is my post-build event:
REM Use the 64-bit sgen from the Win 2008 and .NET 3.5 SDK in a 64-bit dev environment
REM ProgramFiles variable is set to 'Program Files (x86)’ in a x64 environment
REM Processor_Architecture variable returns x86 in both an x86 and x64 environment within VS
if /I "%ProgramFiles%" == "C:\Program Files" (
set ToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.0A\Bin\sgen.exe"
) else (
set ToolPath="C:\Program Files\Microsoft
SDKs\Windows\v6.1\Bin\x64\sgen.exe"
)
%ToolPath% /compiler:"\"/keyfile:$(ProjectDir)
MyKeyFile.snk"\" /force "$(TargetPath)"
