A reader recently (well, recently when I first starting writing this!) asked me to expound upon how I use Virtual PC for development, and I'm more than happy to do so.

I made the switch to Virtual PC for development early last year, so I've worked through quite a few of the issues I ran into, and I'll talk about those, as well as highlight some of the issues that I'm still struggling with, and how I've been able to work around them so far.

The first thing I did was build a base image that had everything on it that I thought I would need. I installed things such as Office, Visual Studio, and MSDN documentation. I used Windows 2003 for a variety of reasons, but the fact that it supports multiple websites and is the environment that I deploy most of the projects I work on were the main factors in my decision.

I didn't start out using Virtual PC. I started doing all development on my laptop, mixing and mashing client environments and hoping there were no conflicts. Well, there were, and that's what led me to Virtual PC in the first place. I say this because that's how I got a list of the software I wanted on my virtual drives. I made a list of all software I had on my machine, went through and eliminated the software I didn't need (another downfall of doing it all on one machine!), and divided it up. I had three lists: Base machine, virtual disk, or both.

So I made one virtual disk with all of the software on it I wanted and configured everything like I wanted - things such as font colors in Visual Studio (I like my strings to be in red, my XML opposite of what is default, etc.), my shortcuts, including setting up TaskSwitchXP and SlickRun with the settings I want. Then I install the latest patches.

After everything was configured like I wanted, I shut it down, and made a copy of it. That copy is what I used for my first client development environment. I renamed it so that I didnt' have naming conflicts, and then I installed the software I needed for their environment (Source OffSite and a VPN client, for the first one I did) and then start using it. Anything I changed that was also on the base, I kept track of as a task to perform on my base image. Any software I started using that I couldn't live without went on a list to be installed on the base.

So what happens when I have a new client that I need a new VPC for? Well, I open up the base, apply any patches, and then work my way through the list I made while using the first VPC. Then I shut it down, and copy it. Then I go through the same process as above.

Why do I copy instead of using differencing disks? First, the patching is key to me. I want to be able to apply patches to my base and not have to do it to every image I base off of that. I know I could have multiple layers of differencing disks, but that just seems?problematic for me to maintain. I'd rather patch and copy, and be ready to go. I don't really use differencing disks at all - I've heard they can grow to be as big as regular disks over time, so I don't see the need. Also, I'm not doing this to test environments, I'm doing it to have isolated environments. Therefore, there's no need for me to use them.

If I was using VMWare on a regular basis, I would go through the same process, except at the end, I'd convert it to a VMWare disk and use it that way. Why start in VPC? Because I can easily convert to VMWare if I need to, but I can't go back the other way.

If you're using VPC or VMWare, what do you do differently, and why?

Technorati Tags: VirtualPC | VMWare | development