With the Windows Azure SDK 1.3 it is now possible to run web roles with Full IIS. If you are unfamiliar with Full IIS you might want to look at this blog which captures the differences between Full IIS and Hosted Web Core (HWC) the only option available with prior SDKs. Additionally you may find this blog, which drills into the impact on the storage configuration setting publisher useful too. The content from those blogs provides context for the rest of this article.

In this post we’ll discuss coding patterns for Windows Azure Drive APIs recommended for use with full IIS. All of these guidelines should work for Hosted Web Core as well. In this context we’ll also discuss one known issue with .Net 4.0. In addition we call out issues that have surfaced with SDK 1.3 and workarounds for them.

Perform Drive Initialization in the Global.asax file

In Full IIS, the OnStart() method in the web role and Page_Load() run in different processes. Consequently a drive letter saved to a global variable in the OnStart method is unavailable to the Page_Load() method. To address this, we recommend that applications perform all drive initialization actions including setting up the cache, creating and mounting the drives in the Application_Start() method of the Global.asax file. This approach is also suitable for Hosted Web Core.

Caveats for .Net 4.0

With .Net 4.0 there is a known issue that will cause all Storage Client API calls for Blobs, Tables and Queues to fail if they are invoked in Application_Start(). The exception surfaced in this case is HttpException (0x80004005): Response is not available in this context” from Global.ApplicationStart” on .NET 4.0.

This issue will be addressed in an upcoming service pack for .Net 4.0. Until then one way to mitigate this issue, is to move all Windows Azure Blob, Table and Queue API calls to some other location like the OnStart() method or to another method in the Global.asax file depending on when the calls need to be executed. It should be noted that the OnStart() method will always execute before Application_Start().

You might also choose to stay with IIS Hosted Web Core until the issue is addressed in the next .Net 4.0 service pack. You can disable Full IIS in an existing project by commenting out the Sites element in the ServiceDefinition.csdef.

In the Storage Emulator with Full IIS, Drives are not visible across user contexts

In the development environment, a drive that is mounted in one user context is not visible in another user context, and the OnStart() and Application_Start methods do not run in the same user contexts. For example if a drive is mounted in the OnStart method and the drive letter passed to the IIS process through some IPC means, the simulated drive will be unavailable in the IIS process when running in the development environment.

When running in the cloud, drives mounted are visible across the entire role instance. Note that with IIS HWC, Page_Load and OnStart are always in the same process and consequently this is not an issue.

Storage Emulator workarounds for Full IIS & SDK 1.3

Update 3/09/011:  The below 3 storage emulator issues have been fixed in the Windows Azure SDK 1.4 release March 2011.

These are a few issues that have surfaced with SDK 1.3 and full IIS that we’ll cover in this section. It should be noted that none of these issues occur with IIS Hosted Web Core.

1. When running in the Windows Azure Emulator, ERROR_UNSUPPORTED_OS is returned from CloudDrive.InitializeCache() when called from Application_Start().

   To work around this issue, set the environment variable AZURE_DRIVE_DEV_PATH to a suitable directory on your system. This directory is used by the Azure Storage Emulator to store Windows Azure Drives.

   To do this, right click on “My Computer”, choose Properties, then Advanced System Settings, then Environment Variables, click “New…” under “System Variables”, name the variable AZURE_DRIVE_DEV_PATH, and set the value to a directory on your machine (e.g. “C:\AzureDriveDevPath”). You should create this path yourself so that any process you create can access it. To propagate this variable to the appropriate processes, you need to reboot your machine.

2. When running with Full IIS on the Windows Azure Emulator on x86 (not x64), the following error is surfaced “Could not load file or assembly ‘mswacdmi.dll’ or one of its dependencies.”

   The workaround is to add the path C:\Program Files\Windows Azure SDK\v1.3\bin\runtimes\storage\simulation\x86 to your system path environment variable. After adding this path, reboot your machine.

3. When running with Full IIS on the Windows Azure Emulator and calling CloudDrive.Snapshot(), the following error is surfaced ‘Unknown Error HRESULT=800040005’.

   This issue crops up because the Storage Emulator uses ‘backup’ semantics to make snapshots, but Full IIS runs as the ‘NETWORK_SERVICE’ user which does not have ‘backup’ rights.

   To work around this problem, you can add ‘NETWORK_SERVICE’ to your ‘Backup Operators’ group. To do so, right click on “Computer” or “My Computer” and choose “Manage”. Go to “Local Users and Groups”, click on “Groups” and then double click on “Backup Operators”. Push “Add”, then “Locations” and select your computer at the top, and push “ok”. Now type ‘NETWORK SERVICE’ without the quotes into the box, and push “Ok”. Finally, push “Ok” again. You should remove ‘NETWORK SERVICE’ from ‘Backup Operators’ when you no longer need this workaround.

Dinesh Haridas