562 votos

¿Cuáles son las diferencias entre AssemblyVersion, AssemblyFileVersion y AssemblyInformationalVersion?

Hay tres conjunto de atributos de versión. ¿Cuáles son las diferencias? Está bien si yo uso AssemblyVersion e ignorar el resto?


MSDN dice:

  • AssemblyVersion:

    Especifica la versión de la asamblea que se atribuyen.

  • AssemblyFileVersion:

    Indica al compilador que utilice un determinado número de versión de los archivos de Win32 versión de recursos. El Win32 versión del archivo no es necesario que sea el mismo que el de la asamblea del número de versión.

  • AssemblyInformationalVersion:

    Define adicional de la información de versión de un manifiesto de ensamblado.


Este es el seguimiento de Cuáles son las mejores prácticas para el uso de los Atributos de Ensamblado?

640voto

Rémy van Duijkeren Puntos 4864

AssemblyVersion

Donde otras asambleas que hacen referencia a su asamblea mirada. Si este número cambia, los demás asambleas tienen que actualizar sus referencias a la asamblea! La AssemblyVersion es necesario.

Yo uso el formato: major.minor. Esto daría como resultado:

[assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Se utiliza para la implementación. Puede aumentar este número para cada implementación. Es utilizado por los programas de instalación. Se usa para marcar las asambleas que tienen el mismo AssemblyVersion, sino que se generan a partir de diferentes generaciones.

En Windows, se puede ver en las propiedades del archivo.

Si es posible, que sea generada por MSBuild. El AssemblyFileVersion es opcional. Si no se da, la AssemblyVersion se utiliza.

Yo uso el formato: major.minor.revision.build, donde puedo utilizar la revisión de la etapa de desarrollo (Alpha, Beta, RC y RTM), service packs y revisiones. Esto daría como resultado:

[assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

La versión del Producto de la asamblea. Esta es la versión que utiliza al hablar con los clientes o para mostrar en su sitio web. Esta versión puede ser una cadena, como '1.0 Release Candidate'. Por desgracia, cuando se utiliza una cadena, va a generar una falsa advertencia -- ya se informó a Microsoft (fijo en VS2010). También el Análisis de Código se quejan de que (CA2243) -- informado a Microsoft (no se fija en VS2013). El AssemblyInformationalVersion es opcional. Si no se da, la AssemblyVersion se utiliza.

Yo uso el formato: major.minor [revisión como una cadena de texto]. Esto daría como resultado:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

422voto

Daniel Fortunov Puntos 12044

Aquí hay un post en el blog me escribió hace poco que profundiza en los detalles de montaje de control de versiones...

El control de versiones de ensamblados en .NET puede ser confuso perspectiva dado que actualmente hay al menos tres formas de especificar una versión para su montaje.

Aquí están las tres principales relacionados con la versión de la asamblea atributos:

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

Por convención, las cuatro partes de la versión se conoce como la Versión Principal, la Versión Menor, Construir, y de Revisión.

La AssemblyFileVersion está diseñada para identificar una compilación de la asamblea individual

Normalmente, podrás configurar manualmente el Mayor y Menor AssemblyFileVersion para reflejar la versión de la asamblea, a continuación, incrementar la generación y/o Revisión cada vez que su sistema de compilación reúne la asamblea. El AssemblyFileVersion debe permitir identificar de forma única una compilación de la asamblea, de modo que se puede utilizar como un punto de partida para la depuración de problemas.

En mi proyecto actual que tenemos el servidor de generación de codificar el changelist número de nuestro repositorio de control de origen, en la construcción y Revisión de las piezas de la AssemblyFileVersion. Esto nos permite asignar directamente desde una asamblea a su código fuente, de cualquier asamblea generado por el servidor de compilación (sin tener que utilizar etiquetas o sucursales en el control de código fuente, o manualmente mantener los registros de las versiones publicadas).

Este número de versión se almacena en la versión Win32 recursos y puede verse al observar el Explorador de Windows las páginas de propiedades de la asamblea.

El CLR no se preocupa ni de examinar la AssemblyFileVersion.

La AssemblyInformationalVersion está destinado a representar la versión completa de su producto

El AssemblyInformationalVersion está destinado a permitir coherente de control de versiones de los productos, que pueden consistir en muchas de las asambleas que están versionados de manera independiente, tal vez con diferentes versiones de las políticas, y potencialmente desarrollados por diferentes equipos.

"Por ejemplo, la versión 2.0 de un producto puede contener varias asambleas; una de estas asambleas es marcado como la versión 1.0 ya que es una nueva asamblea no incluidos en la versión 1.0 de la mismo producto. Normalmente, se establece el mayor y menor de partes de esta versión número para representar la versión pública de su producto. A continuación, puede incrementar la compilación y revisión de partes cada vez empaquetar un producto completo con todas sus asambleas." - Jeffrey Richter, CLR via C# (Segunda Edición), p. 57

El CLR no se preocupa ni de examinar la AssemblyInformationalVersion.

La AssemblyVersion es la única versión del CLR se preocupa por (pero que se preocupa por la totalidad AssemblyVersion)

La AssemblyVersion es utilizado por el CLR se unen a ensamblados con nombre seguro. Se almacena en la AssemblyDef manifiesto de la tabla de metadatos de la asamblea, y en la tabla AssemblyRef de cualquier asamblea a la que hace referencia.

Esto es muy importante, porque significa que cuando se hace referencia a un ensamblado de nombre, que están estrechamente ligadas a un determinado AssemblyVersion de la asamblea. Toda la AssemblyVersion debe ser una coincidencia exacta para la unión a tener éxito. Por ejemplo, si hace referencia a la versión 1.0.0.0 de un ensamblado de nombre al momento de construir, pero sólo la versión 1.0.0.1 de que la asamblea está disponible en tiempo de ejecución, la unión va a fallar! (Usted tendrá que trabajar alrededor de esto usando la Asamblea de Redirección de Enlace.)

Confusión sobre si la totalidad AssemblyVersion tiene que coincidir. (Sí, sí.)

Hay un poco de confusión en torno a si la totalidad de la AssemblyVersion tiene que ser una coincidencia exacta en orden, para que una asamblea para ser cargado. Algunas personas están bajo la falsa creencia de que sólo el Mayor y Menor de partes de la AssemblyVersion tienen que coincidir para que la unión a tener éxito. Esta es una buena suposición, sin embargo en última instancia es incorrecta (como de .NET 3.5), y es trivial comprobar esto para su versión de CLR. Solo tiene que ejecutar este código de ejemplo.

En mi máquina la segunda asamblea de la carga de falla, y las dos últimas líneas de la fusión de registro de dejar perfectamente claro por qué:

.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for  failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, 
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition 
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'

=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
 (Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Creo que el origen de esta confusión es, probablemente debido a que Microsoft pensado originalmente para ser un poco más tolerantes en este estricta coincidencia de la plena AssemblyVersion, haciendo coincidir sólo en la versión Principal y secundaria partes:

"Cuando se carga un ensamblado CLR encontrará automáticamente la última instalado el servicio de la versión que coincide con el mayor/menor de la versión de la la asamblea que se solicita." - Jeffrey Richter, CLR via C# (Segunda Edición), p. 56

Este fue el comportamiento en la versión Beta 1 de la 1.0 CLR, sin embargo esta característica se ha retirado antes de la versión 1.0, y no ha logrado volver a la superficie en .NET 2.0:

"Nota: me acabo de describir cómo se debe pensar en los números de versión. Por desgracia, el CLR no tratar los números de versión de esta manera. [En .NET 2.0], el CLR trata de un número de versión como un cuerpo opaco valor, y si una asamblea depende de la versión 1.2.3.4 de otro asamblea, el CLR intenta cargar versión 1.2.3.4 solo (a menos que una unión la redirección está en su lugar). Sin embargo, Microsoft tiene planes para cambiar el CLR del cargador en una versión futura de modo que carga más reciente construir/revisión para un dado mayor/menor la versión de un ensamblado. Por ejemplo, en una futura versión de CLR, si el cargador está tratando de encontrar la versión 1.2.3.4 de una asamblea y la versión 1.2.5.0 existe, el cargador automáticamente recoger los últimos el servicio de versión. Este será un muy bienvenido a la CLR cargador - I para que uno no puede esperar." - Jeffrey Richter, CLR via C# (Segunda Edición), p. 164 (Énfasis mina)

Como este cambio aún no ha sido implementada, creo que es seguro asumir que Microsoft sigue en esta intención, y tal vez es demasiado tarde para cambiar ahora. Traté de buscar en todo el web para encontrar lo que pasó con estos planes, pero no pude encontrar ninguna respuesta. Todavía quería llegar a la parte inferior de la misma.

Así que le envié un correo a Jeff Richter y le preguntó directamente - pensé que si alguien sabía lo que había pasado, sería él.

Él respondió : dentro de las 12 horas, un sábado de mañana, no menos, y aclaró que el .NET 1.0 Beta 1 cargador hicieron implementar esta automáticos de roll-forward " mecanismo de recoger la última versión disponible de Compilación y Revisión de una asamblea, pero este comportamiento se revirtió antes de .NET 1.0 envía. Más tarde fue destinado a revivir esto, pero no lo hacen antes de que el CLR 2.0 enviados. Luego vino Silverlight, que tuvo prioridad para el CLR equipo, por lo que esta funcionalidad se retrasa más. En tanto, la mayoría de las personas que estaban a su alrededor en los días de CLR 1.0 Beta 1 desde entonces han pasado, por lo que es poco probable que esto se vea la luz del día, a pesar de todo el trabajo duro que ya se habían puesto en él.

El comportamiento actual, parece que está aquí para quedarse.

Es también digno de mención de mi discusión con Jeff que AssemblyFileVersion fue añadido después de la eliminación de la 'automático roll-forward' en el mecanismo, porque después de 1.0 Beta 1, que cualquier cambio en la AssemblyVersion fue un cambio de hora para sus clientes, que no había entonces ningún lugar para almacenar de forma segura su número de compilación. AssemblyFileVersion es que un refugio seguro, ya que nunca automáticamente examinado por el CLR. Tal vez sea más clara de esa manera, tiene dos números de versión, con diferentes significados, en lugar de intentar hacer que la separación entre el Mayor/Menor de edad (romper) y la creación/Revisión (no separación) de las piezas de la AssemblyVersion.

La línea de base: Pensar cuidadosamente acerca de cuando usted cambie su AssemblyVersion

La moraleja es que si eres de envío asambleas que otros desarrolladores están pasando a ser la referencia, debe ser extremadamente cuidadoso cuando usted hace (y no) cambiar el AssemblyVersion de dichas asambleas. Cualquier cambio a la AssemblyVersion significa que los desarrolladores de aplicaciones tendrán que volver a compilar en contra de la nueva versión (para actualizar los AssemblyRef entradas) o utilice el enlace de ensamblado redirige a anular manualmente la unión.

  • No cambio el AssemblyVersion para una versión de servicio que está pensado para ser compatible con versiones anteriores.
  • Hacer cambiar la AssemblyVersion por una liberación que sabe ha de romper los cambios.

Acaba de echar otro vistazo a la versión de los atributos de mscorlib:

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

Tenga en cuenta que es el AssemblyFileVersion que contiene toda la interesante información de servicio (es la Revisión parcial de esta versión que indica a qué Service Pack está), mientras que la AssemblyVersion se fija en un viejo y aburrido 2.0.0.0. Cualquier cambio a la AssemblyVersion obligaría a todos .NET aplicación de referencia mscorlib.dll para volver a compilar en contra de la nueva versión!

29voto

Bob King Puntos 12913

AssemblyVersion bastante permanece interno para .NET mientras AssemblyFileVersion es lo que Windows ve. Si vas a las propiedades de una asamblea sentado en un directorio y cambie a la ficha versión, la AssemblyFileVersion es lo que verás en la parte de arriba. Si usted ordenar los archivos por versión, esto es lo que se usa Explorer.

El AssemblyInformationalVersion mapas para la Versión del Producto "" y está destinado a ser puramente "humano".

AssemblyVersion es sin duda el más importante, pero no me salte AssemblyFileVersion. Si usted no proporciona AssemblyInformationalVersion, el compilador agrega que es para usted por despojarse de la "revisión" de las piezas de su número de versión y salir de la major.minor.build.

18voto

Scott Dorman Puntos 25000

AssemblyInformationalVersion y AssemblyFileVersion se muestran al ver la "Versión" de la información en un archivo mediante el Explorador de Windows mediante la visualización de las propiedades de archivo. Estos atributos, en realidad al ser compilado en un VERSION_INFO recurso que es creado por el compilador.

AssemblyInformationVersion es la "versión del Producto de valor". AssemblyFileVersion es la "versión del Archivo" del valor.

La AssemblyVersion es específico para .NET asambleas y es utilizado por el .NET asamblea cargador para saber que versión de un ensamblado para cargar/enlazar en tiempo de ejecución.

De estos, el único que es absolutamente necesario por .NET es el atributo AssemblyVersion. Unfortunatley también puede causar que la mayoría de los problemas cuando se cambia de manera indiscriminada, especialmente si usted es fuerte nombrar a sus asambleas.

5voto

DavidMBarc Puntos 31

Vale la pena señalar algunas otras cosas:

1) Como se muestra en el Explorador de Windows cuadro de diálogo Propiedades para el ensamblado generado el archivo, hay dos lugares llamados "versión del Archivo". Al visto en el encabezado del cuadro de diálogo muestra la AssemblyVersion, no la AssemblyFileVersion.

En la Otra versión de la sección de información, hay otro elemento que llama "Versión del Archivo". Aquí es donde usted puede ver lo que se ingresó el AssemblyFileVersion.

2) AssemblyFileVersion es sólo texto plano. No tienen que conformar con el esquema de numeración de las restricciones que AssemblyVersion ¿(<build> < 65K, por ej.). Se puede 3.2.<versión texto de la etiqueta>.<fecha y hora>, si te gusta. Su sistema de construcción a fin de cumplimentar las fichas.

Por otra parte, no está sujeto al comodín de reemplazo que AssemblyVersion es. Si usted acaba de tener un valor de "3.0.1.*" en el AssemblyInfo.cs, que es exactamente lo que se mostrará en la Otra versión de la información->Versión de Archivo del elemento.

3) no sé el impacto que un instalador de usar algo que no sea numérico números de versión de archivo, sin embargo.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: