Quick Setup for Testing Internet Explorer in a Virtual Machine
We need to know our users in order to build effective software for them, but we can sometimes have blind spots. As tech professionals, we use the best tools available, but we sometimes fail to adequately consider the platforms and hardware used by our audience. Then the bug report comes in, complete with a totally unrecognizable screenshot. What is THAT? That’s what the fruit of your labor looks like on IE…
It’s not perfect, but it’s the best I’ve got for now. Here’s how it works.
Creating the VM
My Virtual Machine host of choice is VirtualBox. The latest version can be downloaded here, and installation is relatively painless.
Once you have VirtualBox installed, you’ll need a virtual machine image. Microsoft offers a selection of images for various platforms, with browser versions going back to IE 8. (I chose
IE10 on Win7 based on project requirements.)
These machines come with trial versions of Windows, and those trials expire after 90 days. Microsoft suggests making a snapshot before you first start up the VM, which should allow you to roll back and re-start the trial. Of course, you’ll lose any files or settings stored in the VM at that point, so let’s all meet back here in three months, OK?
When you’ve downloaded and unzipped the VM from Microsoft, you’ll find two files: an .ovf file and a .vmdk file. The .ovf file contains the virtual machine configuration, while the .vmdk is the disk file.
To import the VM image, select
Import Appliance from the
File menu in VirtualBox, and navigate to the .ovf file. Click through the wizard, and you’re almost ready to run Windows! Here are some instructions from Oracle.
Updating VM Settings
- Take a Snapshot – Toggle from
Snapshotsin the upper right, and take a snapshot first.
- Base Memory – Find this setting under
Systemand boost the RAM to at least 2G. The more the merrier, but don’t starve your host machine. (under
- Video Memory – Increase it to 128MB under
- Shared Folders – It’s nice to be able to move snippets, logs, etc. between the host and VM. I don’t have anything really long-lived that I want to share between the environments, so I just share my Desktop. Set auto-mount to true so it gets a drive letter.
- Clipboard – Without this, you’ll end up typing every URL from scratch, like I did for the first day. Select the
Bidirectionalfor the shared clipboard.
Inside the VM
The main trick here is connecting to your local development environment. I like to point the VM’s localhost at my laptop so I can simply copy my links (e.g. http://localhost:3000) from my main browser into Internet Explorer on the VM. Here’s how to make that work:
- Open the start menu and type
cmdto find the command-line shell. Right click it, and choose ‘Run as administrator’.
- Figure out where your hosts file lives. Usually it’ll be
- Open the hosts file with notepad from your administrator console, e.g.
- The default VirtualBox NAT configuration maps the host machine to
10.0.2.2. To map that to localhost, just enter
localhost 10.0.2.2at the bottom of the file` and save it.
- Clear your dns cache with
ipconfig /flushdnsand restart any open web browsers.
- Test away!
Doing the Work
- Cache: IE’s caching behavior can be intractable and demoralizing. The dev tools include a cache menu, where you can ask IE to clear cache and always fetch files from the server. You can also enter ‘In Private’ browsing mode from the
Safetymenu. If you’re dealing with source files that have the same path, but differ in query string or live on different servers, the source code viewer may lie to you and show you the first one it saw rather that the active version. I’ve found that once you actually
Start Debugging, the files are refreshed with the code that’s actually running.
- Minified Sources: These older dev tools won’t read sourcemaps or prettify your compressed libraries, so use un-minified development versions whenever possible.
XDomainRequest: If you use this API in your code or via a library, gotchas abound. Headers such as content type don’t behave well, which can break the request parsing code you’ve come to rely on in your framework.
XDomainRequestalso won’t send requests from one protocol to another, even from an
httppage to an
httpsendpoint. I found this post to be a valuable resource.
User driven software development is at the core of our work at Revelry.
Keep in touch by subscribing to CODING CREATIVITY.