Los Web Role corren en una VM que tiene instalado un IIS. Sucede que hasta antes de noviembre para el público en general no era posible controlar todos los aspectos de ese IIS, dado que la arquitectura de Windows Azure usaba un componente llamado Hosted Web Core (HWC) que es apenas un subconjunto del todo el IIS. Quedando por fuera funcionalidades como el soporte a múltiples sitios o aplicaciones virtuales, y la activación de servicios WCF sobre transportes no HTTP a través de los WAS (Windows Activation Services).

Con esta nueva versión tenemos entonces la novedad de Full IIS. Y para decirle a Windows Azure que queremos correr bajo Full IIS en vez de HWC, lo único que tenemos que hacer es agregar una sección de <Sites> en el archivo de definición ServiceDefinition.csdef. Hoy día (versión 1.3), la opción por defecto es correr en Full IIS, así que estos tags se agregan automáticamente con cada nuevo proyecto. Además, cuando migramos un proyecto de 1.2 a 1.3, los tags se agregan automáticamente, dejando la versión lista para correr en Full IIS, lo que puede significar que tengamos que hacer ciertos cambios en la inicialización de los configuradores como lo veremos más adelante. Un ejemplo de esta sección:

Por defecto:

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

Modificado para soportar múltiples sitios:

<Sites>
  <Site name="Web">
    <VirtualApplication name="WebAppA" physicalDirectory="C:\Projects\WebAppA\" />
    <Bindings>
      <Binding name="HttpIn" endpointName="HttpIn" />
    </Bindings>
  </Site>
  <Site name="AnotherSite" physicalDirectory="C:\Projects\AnotherSite">
    <Bindings>
      <Binding hostHeader="anothersite.example.com" name="HttpIn" endpointName="HttpIn"/>
    </Bindings>
  </Site>
</Sites>

Como se aprecia, es supremamente sencillo trabajar con múltiples sitios en un solo web role. Sin embargo, implica un nuevo modelo de hosting combinado en el cual el código compilado en la dll del proyecto cloud no corre en un solo dominio de ejecución (algo extraño para el ojo común) sino que la parte cloud (específicamente el inicializador del WebRole donde está el RoleEntryPoint) se ejecuta en el WaIISHost.exe mientras que el sitio web corre en el tradicional w3wp.exe:

clip_image002

Esta implicación deriva en que los archivos de configuración del WebSite no se puedan leer desde el RoleEntryPoint y viceversa.

Lo primero se soluciona creando un nuevo archivo de configuración llamado WaIISHost.exe.config que contenga las variables inaccesibles del Web.config.

Y en este post, vemos la solución al segundo.