Una de las opciones más sencillas para acondicionar las máquinas en Windows Azure es configurar un startup con los instalables necesarios para frameworks y complementos que utilizamos dentro de nuestra aplicación. La parte negativa de este sistema es que, si necesitamos instalar varios paquetes con el fin de tener varias librerías ubicadas en la GAC de Windows Azure es que  la subida se hace cada vez más lenta debido al peso de cada uno de los instalables.

Si conocemos cuáles son las librerías que necesitamos para que nuestra aplicación funcione correctamente en un entorno que no sea de desarrollo, podemos seguir los siguientes pasos para instalar dichas dll en la GAC sin tener que utilizar un paquete de instalación

En este post vamos a añadir dos librerías a través de un startup. Lo primero que necesitamos localizar es la herramienta gacutil.exe. Esta herramienta nos permitirá realizar la instalación de las dll a través de un bat que utilizaremos como startup. La misma se encuentra en %programfiles%Microsoft SDKsWindowsv7.0ABinNETFX 4.0 Tools y debemos añadir dentro de nuestra solución tanto el archivo gacutil.exe como gacutil.exe.config. Ambos archivos deben tener la propiedad Copy Local a True para que sean incluidos dentro del paquete de subida a Windows Azure. Del mismo modo, las DLL que queramos añadir en la GAC deberán tener este mismo atributo a true para asegurarnos que están dentro de la carpeta bin que se incluirá en la subida.

Una vez establecidos estos pasos, debemos crear un .bat con la siguiente información:

%~dp0gacutil.exe /nologo /i %~dp0Microsoft.IdentityModel.dll

%~dp0gacutil.exe /nologo /i %~dp0EntityFramework.dll

exit /b 0

Lo que estamos haciendo en el mismo es invocar a la herramienta gacutil.exe (el prefijo ~dp0 se utiliza para indicar que ese ejecutable o dll está en la misma carpeta donde se encuentra el .bat que estamos ejecutando) para que se añadan las librerías indicadas en la misma línea a la GAC de la máquina virtual que se está configurando.

Definimos el la tarea dentro del apartado startup del archivo ServiceDefinition.csdef y, del mismo modo, ponemos el atributo Copy Local a True para que sea parte de la subida.

 <WebRole name="Web" vmsize="Small">
    <Startup>
      <Task commandLine="RegisterGAC.bat" executionContext="elevated"></Task>
    </Startup>
    <Sites>

De este modo seremos capaces de añadir dichas librerías sin la necesidad de subir los paquetes de instalación y que la subida sea mucho más liviana.

Espero que sea de utilidad

¡Saludos!

Uno de los requisitos cuando trabajamos con las APIs de administración de Windows Azure es que las peticiones que realicemos utilicen un certificado que anteriormente hayamos subido al portal de Windows Azure. Cuando varias personas trabajan en el mismo proyecto, para no tener que trabajar cada uno con un certificado diferente, lo normal es exportar uno de ellos y que los demás desarrolladores lo importen en sus máquinas para las peticiones a la nube. Llegados a este punto, uno de los problemas que nos podemos encontrar es el siguiente:

Cuando esto ocurre, una de las posibilidades es que, al importar el certificado, el usuario NETWORK SERVICE haya perdido permisos sobre las claves privadas del certificado que permiten firmar la petición (El GUID asignado en cada máquina es diferente). Para solucionar esto, podemos abrir una ventana de Microsoft Management Console (mmc) y añadir el complemento de los Certificates del usuario o del equipo, dependiendo de dónde tengamos importado el mismo. Una vez tengamos localizado el certificado, pulsamos sobre él con el botón derecho y seleccionamos All tasks -> Manage Private Keys…

Dentro de este cuadro de diálogo podremos añadir tanto los grupos y/o usuarios que pueden tener acceso a las claves privadas de este certificado. En el caso de Windows Azure, añadiremos NETWORK SERVICE.

Si ejecutamos de nuevo nuestro código, nuestro emulador tendrá permisos suficientes para poder realizar la petición.

Espero que sea de utilidad

¡Saludos!

Hace unos cuantos días, lo siento por el retraso , uno de mis followers me preguntó si era posible tener un sitio web y un web service en una misma máquina virtual de Windows Azure. Lo cierto es que si Desde que tenemos control total sobre IIS somos capaces de crear tanto sitios, directorios virtuales como aplicaciones virtuales que cuelguen desde el IIS de la máquina virtual de Windows Azure Compute.
Para este post, tengo una pequeña demo donde muestro cómo es posible crear directorios y aplicaciones virtuales dentro de un Web Role. La estructura sería la siguiente:

Como se puede ver en la imagen anterior tenemos dos proyectos: un web role, dentro de este una carpeta llamada statichtml y un proyecto de WCF que será mi servicio web. Por otro lado, en el proyecto de Windows Azure observamos que únicamente tenemos un sólo rol dado de alta. Para poder hacer esta “mezcla” debemos centrarnos en el archivo ServiceDefinition.csdef

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WebRole_WebService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="aspnetWebRole" vmsize="Small">
    <Sites>
      <Site name="Web">
        <VirtualApplication name="myWebService" physicalDirectory="..WcfService">
        </VirtualApplication>
        <VirtualDirectory name="myStaticHtml" physicalDirectory="..aspnetWebRolestatichtml">
        </VirtualDirectory>
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition>

Por decirlo de alguna manera, tenemos un proyecto máster dentro de nuestra solución: aspnetWebRole. Dentro de la configuración del mismo, tenemos un apartado llamado Sites donde podemos añadir tanto sitios nuevos, como directorios virtuales y aplicaciones virtuales.
Para poder definir qué es cada cosa tenemos una serie de tags organizados de forma jerárquica donde definimos qué directorios y qué aplicaciones virtuales pertenecen a qué sitio.

Nota: el atributo physicalDirectory es relativo al archivo ServiceDefinition.csdef. De todos modos, si no nos queda claro cómo montar el path, al intentar publicar el sitio en el apartado Errors de nuestro Visual Studio 2010 nos mostrará la ruta en la cual está intentando buscar.

Si ejecutamos este código a través del emulador y accedemos a nuestro IIS en local, podremos observar que hemos conseguido la siguiente estructura dentro de nuestro servidor web:

Adjunto el proyecto por si fuera de utilidad

¡Saludos!