The Mac/PC dev/QA environment

 Mac/PC Dev Environment

Developing PC applications on the Mac is great, contrary to what some believe. I too was once in the ‘build-on-the-platform-you-target’ camp. Forget that horse-puckie and get efficient:

  1. Get VMware Fusion:
  2. Make sure you’ve got XCode. This will be sixty percent of your development environment and you’ll be coding in OS X.
  3. Install Windows XP or Vista, your choice, as a new VM in Fusion. This will be the other forty percent of your development environment where you’ll step code and delve out builds. Don’t set it up with more than 40% of your Mac’s RAM assigned (preferably 25%).
  4. Install your development tools on this Windows instance, probably .NET 2005.
  5. Set up a shared folder for your source code between your Mac user folder and the dev VM. Make it read-write by both systems (a setting in Fusion).
  6. Set up more VMs in Fusion. These are your Test VMs (smaller, fast Windows instances used as QA machines) – as of this writing you should make XP Home, XP Pro, Vista Home, and Vista Ultimate VMs. You may want additional setups depending on your apps needs (administrator settings, etc). Set these up with 25% or less of your available RAM.
  7. Do nothing… I’m waiting for you to finish step 6… It takes a while.
  8. Run Windows Update (if desired) and take Snapshots of each VM (Command+T) after they’re set up. These Snapshots will let you revert to a clean state any time you wish.

Great, now you’re hooked up and can get your code on. With XCode you can utilize all your monitors (if you’re a developer using less than 2 monitors, we need to talk…). You’ll have XCode running with your source code all over the place organized how you like it. You’ll have your development VM running in a corner.

Use XCode as the code editor (you’ve got your source files saved on the Mac, in the shared folder). Keep the development VM running and hit Control+B in it (or better yet, add an AppleScript to XCode to pass Control+B to the VM) when you need a new build. You can step through the code when you need to.

When you’re ready to test your app(s) on all flavors of Windows, launch up the various VMs and install the app(s). Afterwards, restore to the Snapshot you took before. You’re starting from a nice clean start every time.

17 thoughts on “The Mac/PC dev/QA environment

  1. I’ve tried this workflow, but Visual Studio (both 2005 and 2008) seem very unhappy about building projects that are located in Shared Folders… I tend to get lots of bogus error messages that render it unusable. Is there a trick to avoiding this?

  2. Hey Sol, thanks for the response, but I don’t understand what you mean by “alternate credentials” in this case.

    Steve St. John’s post doesn’t seem relevant to what I’m doing.

  3. Steve St. John’s post describes a situation where you’re getting build errors because of credentials. This seems to be the case when building a project from a shared location.

    The idea is that files from that share are actually set to SYSTEM level permissions. This is why you get the build errors, but it probably doesn’t seem like it. By running the SUBST.EXE, you alter the permissions your system has given to the project so that they’re your own permissions instead of your local SYSTEM’s.

  4. I tried using SUBST.EXE but it made no difference. I usually get errors when attempting to create .idb files.

  5. VMware Workstation lets you debug directly on your test VMs using Visual Studio or Eclipse.

    But it is not yet available on the Mac : (

  6. can you comment of build time overhead when building tons of small files residing in shared folders? when i tried it a while ago, it was significantly slower.

  7. I find it faster than a mapped network drive, but slower than if the
    files were on a local virtual disk. It's noticible for a major
    project, but only on the first build or a clean and build.

    Even for medium sized projects it works very well fe me without a
    significant delay. What kind of delays are you seeing?

    On Tuesday, September 1, 2009, Disqus

  8. sol, thanks for the prompt feedback. as i said, i tried it a long while ago and i haven't tested all the scenarios you mention. but it does have several hundreds of files that change a lot (collaborative env, automatic codegen) and we use incredibuild. it was my ideal scenario to maintain only a single code base on the mac, but the slow compile killed that effort then. i may revisit this approach.

  9. I've gone back and forth between a single codebase on my machine. I never
    had a problem with speed, but for SVN repositories it became a bit
    cumbersome. What I did to get around it was to only handle checkouts and
    commits on the Mac. Originally I was trying to do this on the PC, too, and
    was having trouble.
    Let me know how it goes….

  10. Hey Sol. I'm considering either going this route or parititioning the MacBook HD and using BootCamp/Windows 7 on one half the disk. I can do VMs under the Windows 7 install. Downside of this is that rebooting is required to go from one OS to the other.

    Are you still using this setup? Is it still fast enough using the latest OSs and VMWare? I'm thinking of picking up a MacBook i5 for the work. Think that will work?

    Thanks for an update you might have on all of this.

  11. Hi Paul – this still works like a charm. I strongly advise not to use boot camp unless you absolutely need raw machine level power (gaming, hardware driver development, 100,000,000,000 files open at the same time, etc). An i5 with 4 gigs of memory will be more than enough. You may not want to run 2 vms concurrently, but 1 and OSX will rock.

    Win7 is more efficient than XP, so you'll be even happier than I was when I originally wrote this post!

Leave a Comment

Your email address will not be published. Required fields are marked *