Some time ago I wrote how to deploy multitenant application to the Cloud. The process was tricky at best. With new Windows Azure SDK 1.3 things just got a lot simpler and I absolutely love it. The feature is called Full IIS and allows your web roles to access the full range of web server features that are available in on-premise IIS installations. However if you choose to use them, there are a few differences from the classic Azure Hosted Web Core (HWC) model.

First you need to tell Windows Azure SDK to use Full IIS instead of HWC and you do this by adding a valid <Sites> section to your ServiceDefinition.csdef  file.  By default Visual Studio will create HWC model definition like this:

    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>

You can easily customize it to define multiple web sites, or virtual apps (virtual directories are also supported now):

<Sites>
  <Site name="MainSite">
    <VirtualApplication name="WebApp1" physicalDirectory="D:\Delo\Projects\WebApp1\" />
    <Bindings>
      <Binding name="HttpIn" endpointName="HttpIn" />
    </Bindings>
  </Site>
  <Site name="AnotherSiteOrSubDomain" physicalDirectory="D:\Delo\Projects\ AnotherSiteOrSubDomain ">
    <Bindings>
      <Binding hostHeader="anothersiteorsubdomain.myall.si" name="HttpIn" endpointName="HttpIn"/>
    </Bindings>
  </Site>
</Sites>

Things are much more similar to on-premises application then in HWC model. While RoleEntryPoint  runs under different process (WaIISHost.exe) than your web roles  (w3wp.exe), OnStart method still gets called but configuration settings work a bit differently. You cannot register or store some static values to be available to all websites. Remember its running in a different process... so you wont be able to access its data. What I mean by this is, probably everyone dealing with Azure Development has something similar to this in their role onstart method:

CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>{
    configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});

While code is still perfectly sound, it wont do any good to our web roles, so the proper place to register it would by global.asax on ApplicationStart event. It all kind of makes sense, since different websites need different resources anyway.