I’m not sure how many other people on the planet may want to do this, but I developed a technique which I thought was really cool, and is somewhat non-obvious, so I thought I’d blog about it.

When I develop, out of years of habit, I always install my development environment in a virtual machine, leaving the host with just my productivity software like Outlook. However, the Windows Phone emulator is not supported in a virtual machine. This forced me into installing in my host machine, leaving me with 2 machines:

  1. Host machine, with Visual Studio 2010 Express for Windows Phone
  2. Virtual machine, with Visual Studio Ultimate, SQL Server, Azure tools

Fine. Not what I ideally would have liked, but I can live with that. I was developing a Windows Phone app that calls some RESTful services running on Azure, so my workflow was:

  1. Develop/debug/test RESTful service in VM
  2. Deploy service to Azure
  3. Work on phone app hitting that service live-on-Azure

That worked fine, until I ran into a situation where I was throwing an exception in the RESTful service (due to the data I was submitting), and I had not set up diagnostics for the Azure app. What to do next?

I reasoned that since the host and the VM were on the same network, I should be able to talk between them. However, that would mean using the Windows Phone *emulator* in my host to call into a service running in the Windows Azure *emulator* inside the virtual machine. Can that work? YES!!

Here’s how:

  1. In the VM, run Windows Advanced Firewall and set up inbound and outbound rules to allow full access to port range 81-82 (this is what I did, your mapping may vary, watch the messages as the Azure emulator starts)
  2. In the VM, run the cloud app containing your services, in debug mode with breakpoints set
  3. In the VM, attach to the Azure emulator process (DevFC)
  4. In the VM, do an IPCONFIG to see what your IP address is
  5. In the host, ping that IP address just as a reality check to ensure you can get there
  6. In the host, change your service base URI you are calling to match the VM (in my case it was http://192.168.1.7:82, remember the emulator does port remapping to avoid conflicts)
  7. In the host, run your app and call the service
  8. In the VM, notice that your breakpoint has been hit!

So there you have it: emulator-to-emulator communications with a VM hop in between. Using this technique, you can develop a Windows Phone app running against an Azure backend, debugging both sides at the same time. As an added bonus, you can do this without actually calling anything on Azure, or needing to re-deploy.

Enjoy!


Blog Post by: Brian Loesgen