Cloud Zone is brought to you in partnership with:

Wely is developer, architect, trainer, consultant, technical writer, and technology lover. With the grant of ASEAN Graduate Scholarship, Wely obtained his Master of Science (Information Systems) from Nanyang Technological University. He’s currently working as “Cloud” Solutions Architect in the largest System Integrator in Singapore. Architecting cloud solution, designing and developing cloud project, and delivering cloud training are his daily activities as part of driving the adoption of Cloud Computing, specifically on Windows Azure platform. In spare time, he writes blog, delivers presentation, and participates in online community. His passion in driving Microsoft technologies especially Windows Azure made him to be awarded the first Windows Azure MVP in Southeast Asia. Wely is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. You can read more from them at their website. View Full User Profile

Debugging/Running an ASP.NET Application without Windows

09.11.2012
| 3068 views |
  • submit to reddit

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 than a typical ASP.NET 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

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

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 Studiothat 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

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 acsx directory. Afterwards, Visual Studio lets CSRun deploy and run your package. TheCompute 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

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

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. WithRoleEnvironment.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 class="language-java">public string Setting1
{   get
 {   string setting1 = string.Empty;    if (RoleEnvironment.IsAvailable)   return RoleEnvironment.GetConfigurationSettingValue("Setting1").ToString();   else   return ConfigurationManager.AppSettings["Setting1"].ToString(); } } </code>

Code Fragment 1.1 – Encapsulating the setting with Get property

<code class="language-java"><Role name="AspNetWebApplication">  <Instances count="3" />  <ConfigurationSettings>   <Setting name="Setting1" value="running on Windows Azure environment" />  </ConfigurationSettings>
 </Role> </code>

Code Fragment 1.2 – Setting in ServiceConfiguration.cscfg

<code class="language-java"><appSettings>  <add key="Setting1" value="running as typical ASP.NET project"/>
 </appSettings>  </code>

Code Fragment 1.3 – Setting in web.config

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

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 theRoleEnvironment.IsAvailable returns false, we will get the value from AppSetting in web.config. If we find that it uses Development Storage, we will loadCloudStorageAccount.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 class="language-java">CloudStorageAccount storageAccount;
 if(RoleEnvironment.IsAvailable)
 storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
 else
 { string cs = ConfigurationManager.AppSettings["DataConnectionString "].ToString();
 if (cs.Equals("UseDevelopmentStorage=true"))
 storageAccount = CloudStorageAccount.DevelopmentStorageAccount;
 else  storageAccount = CloudStorageAccount.Parse(cs);
 }
 </code>

Code Fragment 2.1 – Encapsulating the setting with get property

<code class="language-java"><appSettings>  <add key="DataConnectionString"
value="DefaultEndpointsProtocol=https;AccountName={name};AccountKey={key}"/>  <!--<add key="DataConnectionString" value="UseDevelopmentStorage=true"/>-->
 </appSettings> </code>

Code Fragment 2.2 – Setting in ServiceConfiguration.cscfg

<code class="language-java"><Role name="WebRole1">  <Instances count="1" />  <ConfigurationSettings>  <Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=https;AccountName={name};AccountKey={key}" />
 <!-- <Setting name="DataConnectionString" value="UseDevelopmentStorage=true" />-->  </ConfigurationSettings>
 </Role> </code>

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

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

References

 


 
Published at DZone with permission of Wely Lau, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)