Gestión de versiones en el GAC

Cuando se desarrolla una librería para ser distribuida públicamente es normal que esta pueda tener actualizaciones de versiones. Bien porque corrige algunos fallos o porque introduce nueva funcionalidad. Sobre el sistema de versionados ya hablé en un post anterior.

En esta ocasión me quiero centrar en las actualizaciones automáticas de estos ensamblados de las librerías en el GAC. Me explico con un ejemplo. Supongamos que hemos publicado una librería (v1.0.0.0) para que pueda ser usada por múltiples aplicaciones y componentes. Sacamos una nueva versión que corrige algunos errores (v1.0.0.1) y que mantiene la compatibilidad con la versión anterior.

Al ir firmadas con un Strong Name, las aplicaciones ignoran la nueva versión por completo, obligando a que estas deban ser recompiladas haciendo referencia a la nueva versión. Estamos dejando en manos de los desarrolladores que usan nuestras librerías la tarea de actualizar sus aplicaciones a la nueva versión. Si el número de aplicaciones es grande o el problema solucionado es grave (supongamos un agujero de seguridad), el escenario no es muy halagüeño.

Lo ideal es que las aplicaciones se adapten automáticamente a las nuevas versiones de ensamblados sin que a priori se necesite la re-compilación de las aplicaciones. Y digo a priori porque deben ser los desarrolladores de las aplicaciones los que establezcan si realmente quieren este comportamiento o no.

Redirección de versiones de ensamblado

.Net nos permite este tipo de políticas a través de su redirección de ensamblados. Esto es, podemos indicar a una aplicación que use versiones más modernas de un ensamblado.

Este tipo de políticas se pueden realizar en 3 niveles:

• A nivel de aplicación. Cada aplicación decide su política de actualizaciones. Es decir, que versión van a usar en caso de que haya varias versiones del mismo ensamblado, o si realmente no quieren que esta política se lleve a cabo.
• A nivel de máquina. Este es poco frecuente de usar. Normalmente el administrador de la máquina decide si se debe usar una versión concreta o no de un ensamblado en las aplicaciones instaladas que la usan.
• A nivel de proveedor. Los proveedores de las librerías definen en el GAC la política de versiones a usar. De manera que cuando deciden que dos versiones son compatibles, las aplicaciones usarán automáticamente la versión más moderna. Aun así, se puede indicar que una aplicación no siga esta política y que continúe usando la versión de ensamblado con la que fue creado.

En los tres niveles, el esquema para definir la política de redirección se realiza de la misma manera a través de XML:

PublicherPolicyFile.xml

<assemblyBinding> define el bloque de redirección y sólo puede haber uno por fichero de configuración.

<dependantAssembly> puedes tener tantos bloques como necesites aunque cada uno sólo debe contener un elemento <assemblyIdentity>.

<assemblyIdentity> define el nombre del ensamblado a redireccionar y su publicKeyToken para poder ser identificado sin que haya ninguna ambigüedad.   

<bindingRedirect> define la redirección de la versión. en la parte de oldVersion soporta tanto una versión en concreto (como es el caso del ejemplo) como un rango de versiones.

No es necesario indicar de manera individual cada una de las versiones que queremos redirigir. También podemos indicar rangos de versiones y comodines:

Si queremos usar la política de actualizaciones a nivel de aplicación, basta con poner la configuración en el fichero de configuración de la aplicación tal y como se muestra en el código XML anterior.

En caso de ser nosotros los que distribuyamos las librerías, necesitaremos crear un fichero de políticas de versionado a nivel de proveedor. A continuación se explica cómo hacerlo.

Crear un fichero de políticas de proveedor

La creación de este fichero de políticas pasa por 3 sencillos pasos:

1. Crear el fichero XML con la configuración de la política. Básicamente como se hizo en el ejemplo anterior.
2. Crear el ensamblado con la configuración de la política.
3. Añadir el ensamblado con la política de redirección al GAC.

El paso 1 es básicamente crear el fichero tal y como se define en el XML del ejemplo, donde para el ensamblado ArriviSoft.RedirectingAssembllies.Library se ha definido que todos aquellas aplicaciones que referencien a la versión 1.0.0.0, pueden utilizar la versión 1.0.0.1

Para crear el ensamblado que contendrá la política de redirección debemos usar la herramienta Assembly Linker (al.exe) que viene con Visual Studio.

Ejecutamos el siguiente comando:

al.exe /link:PublisherPolicyFile.xml  /out:Policy.1.0.ArriviSoft.RedirectingAssemblies.MyLibrary.dll  /keyfile:ArriviSoft.snk  /platform:x86

donde:

• /link: Indica el fichero xml con la política de redirección de ensamblados.
• /out: Indica el ensamblado que se va a generar y que contendrá la política de redirección. Atención con el formato de nombre de fichero pues debe ser:
  "Policy.majorVersion.minorVersion.NombreEnsamblado.dll"
• /keyfile: Fichero con el par de claves que además debe ser el mismo con el que se firme el ensamblado.
• /platform: Permite definir la plataforma de compilación (x86, amd64, ia64, o MSIL) para afinar mejor.
  Desgraciadamente no podremos generar el mismo ensamblado de políticas si definimos distintas plataformas dado que el nombre del ensamblado resultante sería el mismo. Para solucionarlo bastaría con indicar la plataforma dentro del propio nombre de ensamblado.

Finalmente, una vez tengamos el ensamblado con la política de redirección, este ya puede ser usado en los equipos clientes. El instalador de nuestra librerías debe registrar en el GAC la nueva versión de ensamblados junto con el ensamblado de políticas usando el comando Global Assembly Cache tool (Gacutil.exe)

Ver un PC virtual con VMWare Player desde la red

Hoy ha sido un día un interesante de trabajo para mi compañero Miguel Ángel y para mí. Estamos preparando un sistema de integración continua para nuestro proyecto y nos habíamos decidido por probar la solución de TeamCity, la cual ofrece una versión gratuita. La idea era montar este servicio sobre una unidad virtual en uno de los ordenadores de la red para que el resto del equipo tuviese acceso también.

Creamos la unidad virtual con VMWare Player v3.1.2 con Windows 7 Profesional e instalamos TeamCity sin complicaciones. La nueva unidad virtual puede ver sin problemas el resto de los ordenadores de la red así que configuramos TeamCity para que se conecte a los repositorios de código fuente. Todo perfecto… hasta aquí.

El problema

Si como he dicho antes la unidad virtual podía ver los ordenadores de la red, no era lo mismo al revés. Nadie, ni tan siquiera el host que albergaba a la unidad virtual era capaz de ver al equipo, y por tanto, acceder al servicio.

Buscamos por Internet suponiendo que este problema sería bastante común y que fácilmente encontraríamos la manera de configurar el sistema para solucionarlo. El caso es que no es así, y que además, la manera de solucionarlo es bastante… “truqui del almendruqui”.

Buscando la solución

Lo primero que debemos hacer es configurar la unidad virtual con configuración de red NAT como se muestra en la imagen:

Con esto hacemos que la unidad virtual comparta la misma IP que nuestro equipo host. Pero atención, debemos tener en cuenta que cuando instalamos VMware Player, automáticamente te instala un par de adaptadores de red: VMnet1 y VMnet2. Puedes verlo haciendo una llamada a ipconfig desde la consola:

Para hacer que la unidad virtual utilice de manera correcta el adaptador el adaptador, en nuestro caso VMnet8, necesitamos usar la herramienta de VMware: Virtual Network Editor.

Ya te puedes hinchar de buscar que no la vas a encontrar. Parece ser que no viene con la distribución gratuita de VMware Player. ¿O sí?

Conseguir Virtual Network Monitor

Por lo visto, a los chicos de VMware se les ha ocurrido una curiosa manera de “darte” esta aplicación, pero como si no existiera. En realidad la tienen oculta dentro del fichero de instalación. Para conseguirla tienes que seguir estos pasos:

1. Extrae todo el contenido del instalador mediante la llamada:
c:\> VMware-player-3.1.2.<versión>.exe /e vmware_temp

2. Dentro de la carpeta vmware_temp encontrarás un fichero network.cab. Descomprimelo con WinRAR o 7zip y dentro encontrarás el ejecutable que buscas: vmnetcfg.exe

3. Como este ejecutable tiene muchas dependencias con otras librerías, es aconsejable copiarlo a la carpeta donde esté instalado VMware Player.

4. Listo para configurar.

Configuración con Virtual Network Monitor

Una vez arranquemos la herramienta, realizará una búsqueda de todos los adaptadores de redes virtuales que se encuentren en el PC host. Entre ellos encontrará activados VMnet1 y VMnet8. Nosotros nos centramos en VMnet8. El cual configuramos de la siguiente manera:

Debemos asegurarnos que también esté configurado como NAT y que la IP y la máscara de subred corresponden con lo mostrado en la configuración que muestra el host con el ipconfig que le hicimos en VMnet8.

Con esto ya hemos conseguido configurar el adaptador de red que está asociado a nuestra unidad virtual.

Dado que desde fuera del host, no se tiene acceso a esa subred, y por tanto a la unidad virtual, debemos configurar el NAT para que el host haga de puente entre la red y la unidad virtual. Para ello, asociamos un puerto del host con un puerto de la unidad virtual.

Sabiendo que TeamCity lo que expone es un servicio web y por tanto se accede usando el navegador, configuramos el puerto 8080 del host para que se correspondiera con el puerto 80 de la unidad virtual:

Es interesante destacar que hay que hacerlo tanto para el protocolo TCP y UDP, sino, no funciona.

Y listo. Cualquier ordenador de la red que acceda desde el navegador a la dirección 192.168.14.248:8080, realmente está accediendo a la subred privada 172.16.37.128:80

A continuación la configuración de red de la unidad virtual: