Versionamiento de Assemblies

Para un seguro control de la distribución de las versiones de librerías que forman parte de la aplicación es necesario definir y respetar una política de versionamiento. Cada versión de librería se corresponde con la implementación de una serie de funcionalidades.A continuación una serie de fuertes razones para adoptar una política consistente de versionamiento:
  • Ser capaz de relacionar binarios con código fuente
  • Recrear un build anterior
  • Para evitar el “DLL hell”, múltiples versiones de la misma librería en una máquina
  • Para ayudar al programa de instalación manejar upgrades y service packs.
  • Ayudar al grupo de soporte y help/desk a identificar los bytes con los que están trabajando.
Para ellos, cada archivo de una solución debería tener un número de versión. Las librerías en .NET están representadas por assemblies (exe, dll). Cada uno de ellos se identifican por un número de versión, que es utilizado por el run-time del .NET framework en tiempo de ejecución.

Assembly Version Number

El número de versión es almacenada en el manifiesto de cada assembly junto a otra información de identificación, incluyendo el nombre del assembly y también la información que relaciona el mismo con otros assemblies que en su conjunto forman la aplicación.El número de versión de un assembly se compone de cuatro dígitos separados por puntos:<major version>.<minor version>.<build number>.<revision>Ejemplo: 1.0.2.35Cada dígito tiene su significado:
  • Major version: usualmente asignado por el dueño del componente, debe ser el número interno de versión del producto, rara vez cambia durante el ciclo de desarrollo del release de un producto
  • Minor version: usualmente asignado por el dueño del componente, generalmente usado cuando un release incremental es planeado más que una upgrade de funcionalidad full, rara vez cambia durante el ciclo de desarrollo del lanzamiento de un producto.
  • Build number: asignado por el grupo de desarrollo basado en el número de build, cambia con cada build del código.
  • Revision: asignado por el grupo de desarrollo, puede tener varios significados: numero de bug, numero de buid anterior reemplazado, numero de service pack.
Encontrará que en algunos lugares se recomienda la generación auto incremental del tercer y cuarto dígito. Esto no es recomendable. No use la sintaxis “1.0.*” Recomendamos que el build number y la revision sean explícitamente fijadas en un valor:

This feature is a bug and shouldn't be used because changing the assembly version number will break any assemblies that reference this assembly. The AssemblyInfo.cs file that Visual Studio .Net automatically creates for you when you create a new project is in error:  it sets the AssemblyVersion attribute so that its major and minor parts are 1.0 and that the build and revision parts are automatically updated by the compiler.  You should definitely modify this file and hard-code all four parts of the assembly version number.”

Jeffrey Richter, "Applied Microsoft .Net Framework Programming"

Assembly Informational Version

El Informational Version es un string que acompaña al número de versión del assembly y que sirve a modo informativo solamente, no es utilizado por las aplicaciones en tiempo de ejecución. Generalmente se usa para fijar el nombre comercial de la aplicación, ej.: “Facturacion 1.0”.

StrongNames

Un strong name se compone de la información utilizada para identificar un assembly manifestando que contiene los metadatos del assembly. Esta información incluye:

  • Nombre del texto de la asamblea
  • Número de versión de cuatro partes
  • Información de la cultura (si existe)
  • Una llave pública
  • Firma digital almacenada en el assembly.

Incluir un strong name en un assembly, asegura que dos assemblies con el mismo strong name son idénticos en todos los aspectos, proporcionando la identificación única de un assembly al CLR. Además, la adición de un strong name asegura la integridad binaria permitiendo que el CLR realice la verificación cuando carga al assembly para determinar que no se ha tratado de forzar desde que fue compilado.

Javier Loría explica en su blog Como firmar y autorizar Assemblies 

Agregar a Technorati
Published Wednesday, June 06, 2007 2:14 PM by cwalzer
Filed under:

Comments

# Atributos redundantes del AssemblyInfo.cs de forma centralizada

Friday, November 02, 2007 2:47 PM by Carlos Walzer

Es un hecho factible que alrededor del 90% de las aplicaciones desarrolladas en Visual Studio 2003 o

Leave a Comment

(required) 
(required) 
(optional)
(required) 
Powered by Community Server (Commercial Edition), by Telligent Systems