Your Azure Web Role and Full IIS – Culture Changes

| Comments

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 in w3wp.exe.  This is shown in figure 2.

WaIISHost

This creates some culture changes in the approach previously we did.  I have experimented only on DevFabric and 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 process, 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 held up with two different initialization, 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 as like you normally did in HWC.
  • Static variables in RoleEntryPoint is not accessible from your web application.  Since, these two applications are running in two different process, sharing objects through static variable is not possible in Full IIS.  Instead, try to use machine level environment variable or local resource.