Debugging or Running an ASP.NET Application without Windows Azure Compute Emulator

There are more steps involved in debugging or running a Windows Azure Project than a typical ASP.NET project, so it takes longer. Although you can debug or run the ASP.NET project more quickly when developing a Windows Azure project, there are some restrictions and caveats, as Wely Lau explains.

Recently, one of my .NET developers who was involved in a Windows Azure Project came and asked me two questions:

1. Why does it take longer time to debug or run a Windows Azure Project It takes about 15 to 30 seconds to debug a Windows Azure Project, but only 8 to 15 seconds to debug an ASP.NET project.


Figure 1 – Debugging a Windows Azure Project takes longer than an ASP.NET project

2. Can I debug or run the ASP.NET project instead of the Windows Azure Project when developing a Windows Azure application?


Figure 2 – Setting ASP.NET Web Application as Startup Project

I’ve been looking at the online discussions around these issues and have found they’re very popular questions:

This article will answer and explain these two questions in more detail, including how it really works under the hood, tips and tricks to overcome the issue, and identified limitations.

1. Why does it take longer to debug or run a Windows Azure Project than a typical ASP.NET project?

Windows Azure development tools and SDK

First of all, I need to explain how the Windows Azure development tools and SDK work.

Microsoft enables developers to develop .NET applications targeting Windows Azure easily with the help of Windows Azure SDK (Software Development Kit). The SDK includes assemblies, samples, documentation, emulators, and command-line tools to build Windows Azure applications.

The emulator is designed to simulate the cloud environment, so developers don’t have to be connected to the cloud at all times. The two emulators are: Compute Emulator that simulates the Azure fabric environment and Storage Emulator that simulates the Windows Azure Storage. Apart from emulators, the two important command-line tools are CSPack that prepares and packages the application for deployment and CSRun that deploys and manages the application locally. Other command-line tools can be found here.

Apart from the SDK, there’s an add-in called Windows Azure Tools for Microsoft Visual Studio that extends Visual Studio 2010 to enable the creation, configuration, building, debugging, running, packaging, and deployment of scalable web applications and services on Windows Azure. You will find a new “cloud” template (as can be seen in Figure 3) when adding a new project after installing it. Furthermore, it encapsulates the complexity of running the tools and other commands behind the scenes when we build, run, and publish a Windows Azure Project with Visual Studio.


Figure 3 – Windows Azure project template

The reason why it takes longer

It is true that it takes more time to debug or run a Windows Azure Project than a typical ASP.NET project.

In fact there’s a reasonable rationale behind. When we debug or run a Windows Azure cloud project, all other associated projects (Web / Worker Role) will be compiled and packed into a csx directory. Afterwards, Visual Studio lets CSRun deploy and run your package. The Compute Emulator will then set up and host your web applications in IIS as many as we specify in Instance Count property.


Figure 4 – Websites are being set up in IIS when running Windows Azure Project

As the Full IIS capability was introduced in SDK 1.3, web applications on Windows Azure involve two processes: w3wp.exe which runs your actual ASP.NET application, and WaIISHost.exe which runs your RoleEntryPoint in WebRole.cs / WebRole.vb.

As can be seen, there’re more steps involved when debugging or running a Windows Azure Project. This explains why it takes longer to debug or run Windows Azure Project on Compute Emulator compared to debugging or running an ASP.NET project on IIS or ASP.NET Development Server (Cassini) which is more straightforward.

2. Can I debug or run the ASP.NET project instead of the Windows Azure Project when developing a Windows Azure Project?

Jumping into the next question, is it possible to debug or run ASP.NET project instead of Windows Azure project?

The answer is yes. You can do so simply by setting the ASP.NET project as startup project. However, there are some caveats:

1. Getting configuration settings from Windows Azure Service Configuration

People often store settings at ServiceConfiguration.cscfg in their Windows Azure Project. You can get the setting value by calling RoleEnvironment.GetConfigurationSettingValue("Setting1"). However, you will run into an error when debugging or running the ASP.NET project.


Figure 5 – Error when calling RoleEnvironment.GetConfigurationSettingValue in ASP.NET Project

The reason of getting this error is because the ASP.NET project is unable to recognize and call GetConfigurationSettingValue as the settings belongs to Windows Azure Project.

The Resolution

To resolve this error, there’s a trick we can do as shown in the following code fragments. The idea is to encapsulate the retrieval settings using a get property. With RoleEnvironment.IsAvailable, we are able to determine if the current runs on Windows Azure environment or a typical ASP.NET project. If it doesn’t run on Windows Azure environment, we can get the value from web.config instead of ServiceConfiguration.cscfg. Of course, we need to also store the setting somewhere else such as AppSettings in web.config file.

Code Fragment 1.1 – Encapsulating the setting with Get property

Code Fragment 1.2 – Setting in ServiceConfiguration.cscfg

Code Fragment 1.3 – Setting in web.config

3. Loading a storage account

We normally use the store the Storage Account Connection String in Service Configuration setting as well.


Figure 6 – Setting Storage Connection String in Service Configuration

As such, you might run into similar error again when running the ASP.NET project.

The Resolution

We use similar technique to resolve, but slightly different API. If the RoleEnvironment.IsAvailable returns false, we will get the value from AppSetting in web.config. If we find that it uses Development Storage, we will load CloudStorageAccount.DevelopmentStorageAccount, else we will parse the connection string that is loaded from AppSettings in web.config file. The following code fragments illustrate how you should write your code and configuration.

Code Fragment 2.1 – Encapsulating the setting with get property

Code Fragment 2.2 – Setting in ServiceConfiguration.cscfg

Code Fragment 2.3 – Setting in web.config

An important note: you will still need to turn on Windows Azure Storage Emulator when using this technique.

Catches and Limitations

Although these tricks work in most cases, there are several catches and limitations identified:

  • The technique is only applicable for ASP.NET Web Role, but not Worker Role.
  • Apart from two issues identified, logging with Windows Azure Diagnostic may not work. This may not be a serious concern as we are talking about the development phase, not in production.
  • You are unable to simulate multiple instances when debugging or running ASP.NET project.


To conclude, this article answers two questions.  We have identified some caveats as well as the tricks to overcome these issues.

Although this technique is useful to avoid debugging or running a Windows Azure Project, it doesn’t mean you never need to run as a Windows Azure Project again. I would still recommend you occasionally run the Windows Azure Project to ensure that your ASP.NET project targets Windows Azure perfectly.