Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Hosted-services / Azure

Your Azure Web Role and Full IIS – Culture Changes

0.00/5 (No votes)
16 Sep 2011CC (ASA 2.5)2 min read 13.8K  
Your Azure Web Role and Full IIS – Culture Changes

On Azure SDK v1.3 onwards, your web role can enjoy the benefits full IIS capabilities. It means that your application has now fully controlled by IIS 7.x. Prior to v1.3, your web role was hosted on “Hosted Web Core” (HWC – hmmm, another acronym), a feature introduced in IIS 7.0. HWC can be seen as a raw IIS without having IIS monitoring and administrative features. Hence, you can have your own IIS for a specific web application. It runs in a different process (WaWebHost.exe) and has a dedicated single application pool. So, the mental model of your web role application would be:

WaWebHost

An Azure web role consists of two logical parts in the assembly, one is RoleEntryPoint implementation and another one is your actual web application. Your typical Azure web role has:

  • Web role lifecycle code (RoleEntry OnStart, OnRun and OnStop) and Service model (csdef and cscfg)
  • Web application code and web configuration (web.config)

In HWC, both Web role and web application logical artifacts are resided in a single process (WaWebHost.exe) as shown in figure 1. In the new full IIS capability feature, web role artifacts are loaded into a process called WaIISHost.exe. The web application code as usual is in w3wp.exe. This is shown in figure 2.

WaIISHost

This creates some culture changes in the approach we previously did. I have experimented only on DevFabric and am yet to test on Azure. Probably, I’ll update later. The changes are:

  • Process with different accounts. WaIISHost and w3wp are now running in two different account privileges. Generally, WaIISHost runs in higher privilege and this would cause some code in your web application which was previously enjoyed this high privilege benefit. For example, you can create or access an machine level environment variable from your web application in HWC mode. In Full IIS, this makes exception.
  • Global Configuration Setting Publisher. In HWC, it is enough to initialize global configuration setting publisher once in RoleEntryPoint.OnStart(). However, now in two different processes, you have to again set the publisher either in your framework start up or Application_Start(), otherwise it throws an exception with message “SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used”. Instead of being held up with two different initializations, CloudStorageAccount.Parse() is quite simple and elegant. It just want the connection string detail as a string which can be provided by RoleEnvironment.GetConfigurationSettingValue(…). This is safer too.
  • Application_End will not be encountered. In full IIS, Application_End() will never be called when you stop the debugging like you normally did in HWC.
  • Static variables in RoleEntryPoint are not accessible from your web application. Since these two applications are running in two different processes, sharing objects through static variable is not possible in Full IIS. Instead, try to use machine level environment variable or local resource.

License

This article, along with any associated source code and files, is licensed under The Creative Commons Attribution-ShareAlike 2.5 License