Y tu… ¿que versión estás ejecutando?

Hace pocos días, los Rangers de Visual Studio ALM (que están realizando un excelente trabajo publicando guías y laboratorios sobre diferentes tecnologías) liberaban la guía de personalización de builds con TFS 2010.  En este excelente trabajo, nos explican algunas de las opciones de las que disponemos para personalizar los workflows que se ejecutan por defecto al crear una build automatizada de nuestro proyecto en TFS. Además han liberado también algunas Actividades personalizadas de Workflow Foundation para que las podamos reutilizar cuando personalicemos nuestras builds. Muy recomendable, de verdad.

Leyendo la guía, en un momento dado, aborda un tema que en algún que otro momento hemos necesitado cualquiera de los que nos dedicamos a esto del desarrollo del software, la personalización de la versión de nuestros ensamblados. Conforme vamos avanzando en el desarrollo de un proyecto, y sobre todo, en el momento en que ponemos en producción alguna versión de nuestro producto, éste tiene una versión. Si más adelante descubrimos que esa versión tiene un bug (seguro que no, verdad!!) o cuando añadimos nueva funcionalidad en una versión posterior, nuestros ensamblados DEBEN tener una versión diferente, ya que si no, no seremos capaces de saber qué versión concreta se está ejecutando de nuestra aplicación.

¿Pero cómo gestiona .Net el versionado de nuestros ensamblados?

Pues salvo que estés utilizando alguna utilidad, o una build personalizada que actualice automáticamente las versiones de tus ensamblados, la gestión es completamente manual. Tendrás que buscar alguna fórmula de actualizarla mediante plugins de Visual Studio, Task de MSBuild, u otros mecanismos para automatizarla. Pero primero, entendamos como se definen las versiones.

La opción más sencilla de verificar cual es la versión de tus ensamblados es acceder a las propiedades del proyecto, en la pestaña “Application”, y pulsar en el botón “Assembly information…”. Se abrirá una ventana en la que podemos establecer la versión de nuestra aplicación.

image

Pero espera… ¿La versión? ¡Que versión… ? Aparecen dos versiones… ¿Cual es la que tengo que modificar?

Pues, ¡¡no son sólo dos tipos de versiones sino tres!!

En realidad, estas versiones son atributos que se establecen a nuestro ensamblados, y los podemos encontrar, por defecto, en el archivo “AssemblyInfo.cs” (por defecto el atributo AssemblyInformationalVersion no está definido).image

[assembly: AssemblyVersion(“1.0.0.0”)]
[assembly: AssemblyFileVersion(“1.0.0.0”)]
[assembly: AssemblyInformationalVersion(“1.0.0.0”)]

¿Y para qué sirve cada uno de estos atributos?

  • AssemblyVersion: Es la versión del ensamblado, la que maneja internamente .Net para identificar la versión de nuestros ensamblados. Es la versión que verán otros ensamblados cuando referencien al nuestro. Esta versión forma parte del FullName de nuestro ensamblado, por lo tanto tiene gran importancia si se firman con nombre seguro los ensamblados. El atributo no es obligatorio. Si no se define, la versión será 0.0.0.0.
  • AssemblyFileVersion: Identifica la versión del archivo. Se usa básicamente para identificar un ensamblado en el momento del despliegue. Puede ser usado por programas de instalación. Podemos verlo desde la ventana de propiedades del archivo en el explorador de Windows. No es un atributo obligatorio. Si no se define, se usa la versión de AssemblyVersion.
  • AssemblyInformationalVersion: Identifica la versión del producto. Puede tener un formato diferente a las anteriores, ya que puede incluir texto libre en la versión, por ejemplo “2.0 RC1”. Podemos verlo desde la ventana de propiedades del archivo en el explorador de Windows. Si no está definida, se usa la versión de AssemblyFileVersion.

image

Algunas curiosidades con el número de versión

En el atributo AssemblyVersion, podemos usar un * para sustituir los dos últimos número (la Build y la Revision). El compilador genera estos dos números de manera automática. Por lo tanto, serían válidas versiones como “2.3.15.*” o “2.3.*”.

En cambio, el atributo AssemblyFileVersion no soporta este formato de versionado. Si el compilador se encuentra con algo parecido a “2.3.*” en el atributo AssemblyFileVersion, generará un warning en la compilación y se establecerá la versión a “2.3.0.0”. En cambio, y como cosa curiosa, si no hemos establecido el atributo AssemblyInformationalVersion, éste mostrará la versión “2.3.*”.

Esto pasa porque, como hemos comentado antes, AssemblyInformationalVersion soporta formatos que no sigan la definición de <major.minor.buils.revision>, por lo que aquí sería válido establecer la versión como “2.0 RTM” o “2.0 SP1”.

Acceso mediante código a las diferentes versiones

Mediante código, podemos acceder a las tres diferentes versiones de un ensamblado, y por lo tanto, mostrar al usuario la que nosotros queramos.

Para AssemblyVersion:

Assembly assembly = Assembly.GetExecutingAssembly();
// O cualquier otra forma de recuperar una instancia de tipo Assembly Version version = assembly.GetName().Version;

Para AssemblyFileVersion y paraAssemblyInformationalVersion:

Assembly assembly = Assembly.GetExecutingAssembly();
// O cualquier otra forma de recuperar una instancia de tipo Assembly FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location); string fileVersion = fileVersionInfo.FileVersion; string productVersion = fileVersionInfo.ProductVersion;

Destacar que la versión de AssemblyVersion es una instancia del tipo Versión, mientras que la versión de AssemblyFileVersion y la de AssemblyInformationalversion es un string ya formateado.

 

Para más información:

http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyinf

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyfileversionattribute.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyinformationalversionattribute.aspx