I was recently giving a presentation on Windows Azure at CodeMash. As part of my presentation I was going to give a demonstration on adding a new worker role to an existing solution. All was going well until I hit F5 to start up Windows Azure’s local compute and storage emulators. And then, sure enough, the demo gods frowned upon me and caused my demo to experience a dreaded YSOD (yellow screen of death).
The error message I received was completely new to me – “Not running in a hosted service or the Development Fabric”. My first thought was “you’ve got to be kidding me . . . now?!?” My second thought was that I had inadvertently set my web role (an ASP.NET MVC2 project) as the startup project instead of the Azure project. A quick check confirmed that my Azure project was indeed the startup project. Hmm . . . now what? I looked at my ServiceConfiguration.cscfg and ServiceDefinition.csdef files to make sure they were correct. They were. Great. I moved on with other parts of my presentation as gracefully as I could.
After the session was over I continued to question what went wrong. I distinctly remember quickly testing my demo prior to the presentation. I also remember closing all my extra open programs (TweetDeck, Outlook, etc.) just to make sure there were no crazy pop-ups during the presentation. As part of closing some of those programs I accidentally closed the Windows Azure Compute Emulator. I proceeded to quickly start it back up by doing so from the program menu (Start -> All Programs -> Windows Azure SDK v1.3 -> Compute Emulator). The thought being that if it was running ahead of time I could have saved a few seconds on the demo. All good, right? Yeah, I thought so too.
I spent some time trying to figure out what was wrong. The code looked good. The configuration looked good. I shut down everything, reopened Visual Studio, and loaded my demo project again. I fired up the project and sure enough it worked!! I did a little searching online for the error message I received. Nothing hit on it exactly, but a few were close. One post suggested that perhaps the emulator was not started as an Administrator. That’s when it hit me. I didn’t start the local Compute Emulator as an Administrator! Visual Studio automatically starts the Compute Emulator when debugging an Azure project – but only if the Compute Emulator isn’t already running. Since Visual Studio starts as an Administrator (which is needed for Windows Azure development), the Compute Emulator starts up as an Administrator too.
Notice the red line of code in the error screen – “Trace.WriteLine(“hello world”);” and the message in the stack trace, “Could not create Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener . . . . .”. Turns out this was the key. Most of the Azure diagnostics require administrative rights. Since the Windows Azure Compute Emulator was not started as an Administrator, the API calls failed.
The solution – start the Windows Azure Compute Emulator as an Administrator, or let Visual Studio start the emulator (provided Visual Studio is already running with administrative rights). I know this isn’t groundbreaking or anything, but I thought I would share my experiences in hopes it might help someone else.