Integrating an automatic build on a windows host with the rest of your one-command cross-platform build system can be quite a pain. Luckily there is cygwin which makes things like ssh, bash, make etc all work on windows. It's great.
The trick to building using visual studio from there is to use the
devenv.com tool, which is a version of the full blown visual studio (
devenv.exe) that does not pop up windows on your screen (ahem, should not- see below) but instead shows all output nicely on your terminal (which you tee to the logfiles of your build system of course). Life still looks good.
So you set up your build system to do remote, unattended logins to the windows build slave using ssh public keys. This is trivial as you do this on all your build slaves. But all of a sudden
devenv.com just hangs. That's weird. Do some searching on the mighty Internet and it turns out there's a bug somewhere in Mircosofts authentication handling. There is some token that does something weird and somehow when you use public key authentication visual studio 2003 (and 2005) think they're the system service (since that is what the ssh service runs as) and don't run properly (various errors possible). But everyone reports errors instead of just hanging, how is this possible? So you go to the ssh service and tick the "Allow service to interact with desktop" box, restart ssh and try again. Success! Now you get a window from
devenv.com that visual studio crashed on the screen. Never mind that
devenv.com was supposed to be command-line only.
But still not closer to the solution. It turns out that Microsoft actually fixed this error for visual studio 2005, but you're stuck with 2003 for some reason.
Time for ugly solutions.
Since this Windows box is a build slave anyway, it's not supposed to be used for anything else. So the only account of use on it is the one used by the build system. What if we run the ssh service in the name of this account? This requires some fiddling with the permissions of the ssh files (
/var/log/sshd.log) in cygwin, but once the ssh service is happy and wants to start it all works! No more errors from
Ugly, but it finally works.