views:

63

answers:

1

Our team recently got new dev machines, but our team lead has a special case that needs to be addressed and I'm not really sure the best way to set it up.

The particulars...

  • New machines are running Server 2008
  • Visual Studio 2008 and sometimes 2005
  • We have a virtual machine of XP setup on our machines, for cases like this
  • Sigh Yes we have Visual SortaSafe (I've tried to get them to move, but...)

My problem is our lead has special drivers for a legacy database that have to be used for the next year (then it gets replaced), and they won't work on Server 2008. We installed them on her XP VM, but now the question is how to set this whole conflaguration up to run those applications on XP, but still allow her to run her VS, etc on the new machine to take advantage of the speed rather than installing it twice. I got remote debugging working so-so, but it's a pain, and since VSS doesn't allow multiple working folders she's going to have to copy some of the libraries between 'machines' every time.

Is there a simple answer I'm missing to set this up. I'm trying to make it as seamless as possible so it's not a giant pain. Or am I stuck with a second VS install on XP or taking 2 aspirin and work with the remote debugger? Maybe this has already been answered somewhere I'm not finding?

Edit: Turns out we're just going to cheat with her machine. We're going to put her old one in the corner and she can remote it when she needs to work on those projects. I'm curious though if anyone has any more creative ideas. Joe's idea won't work as we aren't able to program against the drivers (not ours). I got something working with Post-build events and the remote debugger - anything better?

A: 

I would suggest building a facade style layer between the application and the legacy drivers. Then you could do all the development and testing using a stub that works on server 2008 and the actual drivers on the XP VM.

Joe Caffeine

related questions