A Tale of Two Emulators and a VM

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, 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.



DevCamp Irvine is this Friday April 20th


I’ll be at DevCamp:Cloud this Friday at the UC Irvine campus. The L.A. event was sold out, and most stayed all day. Lots of good info.

See you there?

Register here at


DevCamp Los Angeles is tomorrow


I’ll be at DevCamp:Cloud tomorrow March 30th in Los Angeles. See you there?


Feb 29 2012 Outage Explanation

There was an Azure outage on Feb 29th. While these things can happen, it was really refreshing to see the openness and degree of detail in the explanation of the root cause analysis and the events that followed. The post will also give you some technical insights into what goes on behind the scenes.

You can read about it here:


New Azure ServiceBus Demo Available

I’m pleased to announce that I FINALLY have finished and packaged up a cool little ServiceBus demo.

I say “finally” because this demo has a long lifeline, it began over a year ago. I enhanced it, and showed it to a colleague, Tony Guidici, for his comments. He ended up enhancing it, and putting it into his Azure book. I then took it back, enhanced it further, and, well, here it is. Thanks also to my colleagues David Chou and Greg Oliver for their feedback.

There are several resources associated with this demo:

Note that this is based on the current-when-I-did-this version 1.6 of the Azure SDK and .NET libraries.

At a high level, the scenario is that this is a system that listens for events, and when critical events occur, they are multicast to listeners/subscribers through the Azure ServiceBus. The listeners use the ServiceBus relay bindings, the subscribers use the topical pub/sub mechanism of the ServiceBus.

Why relay *and* subscription? They serve different models. For example, using the subscription model, a listener could subscribe to all messages, or just a subset based on a filter condition (in this demo, we have examples of both). All subscribers will get all messages. By contrast, a great example of the relay bindings is having a Web service deployed on-prem, and remoting that by exposing an endpoint on the ServiceBus. The ServiceBus recently introduced a load balancing feature, where you could have multiple instances of the same service running, but if a message is received only one of them is called.

Both models work very well for inter-application and B2B scenarios. Note that this demo is intended to show the various parts of the ServiceBus, in a real world scenario you would likely not have a subscription listener that in turn publishes to a relay.

The moving parts in this particular demo look like this:


Subscriptions are shown above as ovals, the direct lines are relay bindings. The red lines are critical events, the black line is all events.

The projects in the solutions are:


Their purposes are:

EventPoint.ConsoleApp Listens for critical messages multicast through the ServiceBus relay binding
EventPoint.ConsoleApp.Topics Listens for critical messages multicast through the ServiceBus eventpoint-topics namespace
EventPoint.Generator Test harness, publishes messages to the ServiceBus eventpoint-topics namespace
EventPoint.Monitor WinForms app that listens for critical messages multicast through the ServiceBus relay binding
EventPoint.CriticalPersister Listens for critical messages multicast through the ServiceBus relay binding and persists them to SQL Azure
EventPoint.Data Message classes
EventPoint_WebRole Table browser UI to see all events that have been persisted to Azure table storage
EventPoint_WorkerRole Worker role that sets up eventpoint-topics subscriptions for 1) All events and 2) critical (priority 0) messages that get multicast to the ServiceBus relay
EventPoint.Common Config, message factory to support push notifications
Microsoft.Samples.ServiceBusMessaging NuGet package to support push notifications


There are a few things you’ll need to do in order to get the demo working. Remarkably few things actually, considering the number of moving parts in the flow diagram!

First off, in the admin portal, you will need to create two ServiceBus namespaces:


NOTE THAT SERVICEBUS NAMESPACES MUST BE GLOBALLY UNIQUE. The ones shown above are ones I chose, if you want to run the code you will have to choose your own and cannot re-use mine (unless I delete them).

The “eventpoint-critical” namespace is used for the relay bindings, the “eventpoint-topics” is used for the pub/sub (apparently you cannot use the same namespace for both purposes, at least at the time this was written). You don’t have to use those names, but if you change them, you’ll need to change them in the config file too, so I’d suggest just leaving it this way.

Because there are multiple types of apps, ranging from Azure worker roles through console and winforms apps, I created a single shared static config class that is shared among the apps. You can, and need to, update the app.config file with your appropriate account information:


Note: there are more things you need to change that did not fit in the screen shot, they will be self-evident when you look at the App.Config file.

To get the ServiceBus issuer name and secret, you may need to scroll as it is bottom-most right-hand side of the ServiceBus page:


Lastly, you’ll need to add the name/creds of your storage account to the Web and worker roles.

When you run the app, five visible projects will start, plus a web role and a worker role running in the emulator.

In the screen shot below, I generated 5 random messages. Three of them were critical, and you can see they were picked up by the console apps and the WinForms app.


Just as with Windows Azure queues, the Azure ServiceBus is a powerful tool you can use to decouple parts of your application. I hope you find this demo helpful, and that it gives you new ideas about how you can use it in your own solutions.


Azure Discovery Events

We are going to be running another series of Windows Azure  Discovery events in US West region.

Azure Discovery Events

We would like to offer you the opportunity to attend the Windows Azure Platform Discover Event. A Discover Event will provide a business and technical overview of the Windows Azure Platform. The target audience for these events includes business decision makers, technical decision makers, architects, and development leads. The sessions are targeted at the 100-200 level with a mix of business focused information as well as technical information.





January 31, 2012

Redmond, WA

9:00 AM – 1:00 PM

Register here

February 8, 2012

Boulder, CO

9:00 AM – 1:00 PM

Register here

February 27, 2012

Mountain View, CA

9:00 AM – 1:00 PM

Register here

March 1, 2012

Irvine, CA

9:00 AM – 1:00 PM

Register here

To register by phone, call: 1.877.MSEVENT (1.877.673.8368).


Christmas came early–December Azure update is HUGE

There’s just too much to talk about in today’s December update to Windows Azure. There are enhancements across the board, starting with the initial sign-up experience, through to billing, and EVERYTHING in between. There have been pricing updates, SQL Azure size has gone up to 150gb, SQL Federation has now shipped (no longer CTP) enabling massive scale/perf SQL solutions, portal updates….

I could go on and on, but instead, read the official post here.

Page 1 ... 2 3 4 5 6 ... 37 Next 7 Entries »