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


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


MSDN dice:

  • AsambleaVersión:

    Especifica la versión del ensamblaje que se atribuye.

  • AssemblyFileVersion:

    Indica a un compilador que use un número de versión específico para el recurso de versión de archivo Win32. No es necesario que la versión del archivo Win32 sea la misma que el número de versión del ensamblaje.

  • AssemblyInformationalVersion:

    Define información de versión adicional para un manifiesto de ensamblaje.


Este es un seguimiento de ¿Cuáles son las mejores prácticas para usar los atributos de ensamblaje?


766
2017-09-15 16:47


origen


Respuestas:


AsambleaVersión

Donde se verán otros ensambles que hacen referencia a su ensamblaje. Si este número cambia, ¡otros ensambles tienen que actualizar sus referencias a su ensamblaje! los AssemblyVersion es requerido.

Yo uso el formato: Mayor Menor. Esto daría como resultado:

[assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Usado para despliegue Puede aumentar este número para cada implementación. Es utilizado por los programas de instalación. Úselo para marcar conjuntos que tienen el mismo AssemblyVersion, pero se generan a partir de diferentes compilaciones.

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

Si es posible, permita que sea generado por MSBuild. AssemblyFileVersion es opcional. Si no se proporciona, se utiliza AssemblyVersion.

Yo uso el formato: major.minor.revision.build, donde utilizo revisión para la etapa de desarrollo (Alpha, Beta, RC y RTM), paquetes de servicio y arreglos urgentes. Esto daría como resultado:

[assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

La versión del producto del ensamblaje. Esta es la versión que usaría al hablar con los clientes o para mostrar en su sitio web. Esta versión puede ser una cadena, como '1.0 Release Candidate'.

El Code Analysis se quejará al respecto (CA2243) - informado a Microsoft (no corregido en VS2013).

los AssemblyInformationalVersion es opcional. Si no se proporciona, se utiliza AssemblyFileVersion.

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

[assembly: AssemblyInformationalVersion("1.0 RC1")]

822
2017-09-15 17:46



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

Estos son los tres principales atributos de ensamblaje relacionados con la versión:

// 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 conocen como Versión principal, Versión menor, Construiry Revisión.

los AssemblyFileVersion tiene la intención de identificar de manera única una construcción de la montaje individual

Normalmente, configurará manualmente Major y Minor AssemblyFileVersion para reflejar la versión del ensamblado, luego incrementará la compilación y / o revisión cada vez que su sistema de compilación compile el conjunto. AssemblyFileVersion debe permitirle identificar de manera única una compilación del ensamblado, para que pueda usarlo como punto de partida para eliminar cualquier problema.

En mi proyecto actual, el servidor de compilación codifica el número de lista de cambios de nuestro repositorio de control de origen en las partes de compilación y revisión de AssemblyFileVersion. Esto nos permite mapear directamente desde un ensamblaje a su código fuente, para cualquier ensamblado generado por el servidor de compilación (sin tener que usar etiquetas o ramas en el control de fuente, o mantener manualmente ningún registro de las versiones publicadas).

Este número de versión se almacena en el recurso de la versión de Win32 y se puede ver cuando se visualizan las páginas de propiedades de Windows Explorer para el ensamblaje.

El CLR no se preocupa ni examina el AssemblyFileVersion.

los AssemblyInformationalVersion pretende representar la versión de su producto completo

El AssemblyInformationalVersion está diseñado para permitir el control de versiones coherentes de todo el producto, que puede consistir en muchos ensambles que tienen versiones independientes, quizás con políticas de versiones diferentes, y que pueden ser desarrollados por equipos diferentes.

"Por ejemplo, la versión 2.0 de un producto   podría contener varios ensambles; uno   de estos conjuntos está marcado como   versión 1.0 ya que es un nuevo ensamblaje   que no se envió en la versión 1.0 de la   mismo producto. Por lo general, configura el   partes principales y menores de esta versión   número para representar la versión pública   de tu producto Entonces usted incrementa   las partes de construcción y revisión cada vez   empaca un producto completo con   todas sus asambleas ".              - Jeffrey Richter, [CLR a través de C # (Segunda edición)] p. 57

El CLR no se preocupa ni examina la AssemblyInformationalVersion.

los AssemblyVersion es la única versión que le importa a CLR (pero se preocupa por la totalidad AssemblyVersion)

AssemblyVersion es utilizado por el CLR para enlazar a ensamblajes fuertemente nombrados. Se almacena en la tabla de metadatos del manifiesto AssemblyDef del ensamblado construido y en la tabla AssemblyRef de cualquier ensamblaje que haga referencia a él.

Esto es muy importante, porque significa que cuando hace referencia a un ensamblado con un nombre fuerte, está estrechamente vinculado a una AssemblyVersion específica de ese ensamblaje. Toda la AssemblyVersion debe ser una coincidencia exacta para que la vinculación tenga éxito. Por ejemplo, si hace referencia a la versión 1.0.0.0 de un ensamblado fuertemente nombrado en tiempo de compilación, pero solo la versión 1.0.0.1 de ese ensamblado está disponible en tiempo de ejecución, ¡el enlace fallará! (Entonces tendrá que solucionar esto utilizando Redirección de enlace de ensamblaje.)

Confusión sobre si todo el AssemblyVersion tiene que coincidir. (Sí, lo hace)

Existe una pequeña confusión acerca de si toda la AssemblyVersion tiene que ser una coincidencia exacta para poder cargar un ensamblaje. Algunas personas tienen la falsa creencia de que solo las partes Mayor y Menor de la Versión de la Asamblea tienen que coincidir para que la vinculación tenga éxito. Esta es una suposición sensata, sin embargo, en última instancia es incorrecta (a partir de .NET 3.5), y es trivial verificar esto para su versión del CLR. Simplemente ejecuta este código de muestra.

En mi máquina, la segunda carga de ensamblaje falla, y las últimas dos líneas del registro de fusión dejan 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 probablemente se debe a que originalmente Microsoft tenía la intención de ser un poco más indulgente con esta concordancia estricta de AssemblyVersion completa, haciendo coincidir solo las partes de la versión Major y Minor:

"Al cargar un conjunto, el CLR encontrará automáticamente el último   versión de servicio instalada que   coincide con la versión mayor / menor de la   montaje solicitado ".               - Jeffrey Richter, [CLR a través de C # (Segunda edición)] p. 56

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

"Nota: Acabo de describir cómo   debería pensar en los números de versión.   Desafortunadamente, el CLR no trata   números de versión de esta manera. [En la red   2.0], el CLR trata un número de versión como un valor opaco, y si un ensamblaje   depende de la versión 1.2.3.4 de otro   ensamblaje, el CLR intenta cargar   versión 1.2.3.4 solamente (a menos que un enlace   la redirección está en su lugar). Sin embargo,    Microsoft tiene planes para cambiar el   Cargador de CLR en una versión futura por lo   que carga la última   construcción / revisión para un mayor / menor dado   versión de un ensamblaje. Por ejemplo,   en una versión futura del CLR, si el   cargador está tratando de encontrar la versión   1.2.3.4 de un conjunto y la versión 1.2.5.0 existe, el cargador recoge automáticamente la última   versión de servicio. Esta será una muy   bienvenido cambio al cargador de CLR - I   porque uno no puede esperar ".               - Jeffrey Richter, [CLR a través de C # (Segunda edición)] p. 164 (Énfasis   mía)

Como este cambio todavía no se ha implementado, creo que es seguro suponer que Microsoft se ha retrasado en esta intención, y que quizás sea demasiado tarde para cambiar esto ahora. Traté de buscar en la web para averiguar qué sucedió con estos planes, pero no pude encontrar ninguna respuesta. Todavía quería llegar al fondo del asunto.

Entonces le envié un correo electrónico a Jeff Richter y le pregunté directamente: pensé que si alguien sabía lo que sucedió, sería él.

Respondió en menos de 12 horas, un sábado por la mañana nada menos, y aclaró que la cargadora .NET 1.0 Beta 1 implementó este mecanismo de 'avance automático' para recoger la última compilación y revisión disponible de un ensamblaje, pero este comportamiento fue revertido antes de .NET 1.0 enviado. Posteriormente, se intentó revivir esto, pero no apareció antes de que se enviara el CLR 2.0. Luego vino Silverlight, que tuvo prioridad para el equipo de CLR, por lo que esta funcionalidad se retrasó aún más. Mientras tanto, la mayoría de las personas que estaban en la época de CLR 1.0 Beta 1 ya han avanzado, por lo que es poco probable que esto vea la luz del día, a pesar de todo el trabajo duro que ya se le ha dedicado.

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

También vale la pena señalar de mi discusión con Jeff que AssemblyFileVersion solo se agregó después de la eliminación del mecanismo de 'reenvío automático', porque después de 1.0 Beta 1, cualquier cambio en la AssemblyVersion fue un cambio radical para sus clientes, hubo entonces en ninguna parte para almacenar de forma segura su número de compilación. AssemblyFileVersion es ese refugio seguro, ya que nunca es examinado automáticamente por el CLR. Tal vez sea más claro de esa manera, teniendo dos números de versión separados, con significados por separado, en lugar de tratar de hacer esa separación entre las partes Mayor / Menor (rompimiento) y Construir / Revisión (sin romper) de AssemblyVersion.

El resultado final: piense cuidadosamente sobre cuándo cambia su AssemblyVersion

La moraleja es que si está enviando ensamblajes a los que otros desarrolladores harán referencia, debe ser extremadamente cuidadoso cuando cambia (y no modifica) AssemblyVersion de esos ensamblajes. Cualquier cambio en AssemblyVersion significará que los desarrolladores de aplicaciones tendrán que volver a compilar contra la nueva versión (para actualizar esas entradas de AssemblyRef) o usar redireccionamientos de enlace de ensamblaje para anular manualmente el enlace.

  • No haga cambie AssemblyVersion por una versión de mantenimiento que sea compatible con versiones anteriores.
  • Hacer cambie AssemblyVersion por un lanzamiento que sepa que tiene cambios de última hora.

Solo eche un vistazo a los atributos de la versión en 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 la AssemblyFileVersion la que contiene toda la información de servicio interesante (es la parte de revisión de esta versión que le dice en qué Service Pack se encuentra), mientras tanto, AssemblyVersion está arreglada en un viejo y aburrido 2.0.0.0. ¡Cualquier cambio en AssemblyVersion obligaría a todas las aplicaciones .NET que hacen referencia a mscorlib.dll a volverse a compilar contra la nueva versión!


541
2018-04-29 12:01



AssemblyVersion prácticamente se mantiene interno a .NET, mientras AssemblyFileVersion es lo que ve Windows. Si va a las propiedades de un conjunto sentado en un directorio y cambia a la pestaña de versión, AssemblyFileVersion es lo que verás arriba. Si ordena los archivos por versión, esto es lo que utiliza Explorer.

los AssemblyInformationalVersion se asigna a la "Versión del producto" y está destinado a ser puramente "usado por el ser humano".

AssemblyVersion es sin duda la más importante, pero no me saltaría AssemblyFileVersion, ya sea. Si no proporciona AssemblyInformationalVersion, el compilador lo agrega para usted quitando la pieza de "revisión" de su número de versión y dejando major.minor.build.


39
2017-09-15 16:51



AssemblyInformationalVersion y AssemblyFileVersion se muestran cuando visualiza la información de "Versión" en un archivo a través del Explorador de Windows al ver las propiedades del archivo. Estos atributos realmente se compilan en un VERSION_INFO recurso creado por el compilador.

AssemblyInformationalVersion es el valor de "Versión del producto". AssemblyFileVersion es el valor de "Versión de archivo".

los AssemblyVersion es específico de los ensamblados .NET y lo utiliza el cargador de ensamblaje .NET para saber qué versión de un ensamblaje cargar / vincular en tiempo de ejecución.

De estos, el único requerido por .NET es el AssemblyVersion atributo. Desafortunadamente también puede causar la mayoría de los problemas cuando cambia indiscriminadamente, especialmente si usted está dando un nombre fuerte a sus ensamblajes.


21
2017-09-15 16:52



Vale la pena mencionar algunas otras cosas:

1) Como se muestra en el cuadro de diálogo Propiedades del Explorador de Windows para el archivo de ensamblaje generado, hay dos lugares llamados "Versión de archivo". El que se ve en el encabezado del diálogo muestra AssemblyVersion, no AssemblyFileVersion.

En la sección Información de otra versión, hay otro elemento llamado "Versión de archivo". Aquí es donde puede ver lo que se ingresó como AssemblyFileVersion.

2) AssemblyFileVersion es solo texto sin formato. No tiene que ajustarse a las restricciones del esquema de numeración que realiza AssemblyVersion (<build> <65K, por ejemplo). Puede ser 3.2. <Release tag text>. <Datetime>, si lo desea. Tu sistema de compilación tendrá que completar los tokens.

Además, no está sujeto al reemplazo de comodín que AssemblyVersion. Si solo tiene un valor de "3.0.1. *" En AssemblyInfo.cs, eso es exactamente lo que se mostrará en el elemento Otra versión información-> Versión de archivo.

3) No sé el impacto en el instalador de usar algo más que números de versión de archivo numérico.


7
2017-11-27 22:51



Para mantener esta pregunta actualizada, vale la pena resaltar que AssemblyInformationalVersion es utilizado por NuGet y refleja el versión del paquete incluyendo cualquier sufijo de prelanzamiento.

Por ejemplo, una AssemblyVersion de 1.0.3. * Empaquetada con asp.net core dotnet-cli

dotnet pack --version-suffix ci-7 src/MyProject

Produce un paquete con la versión 1.0.3-ci-7 que puede inspeccionar con reflexión utilizando:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

6
2018-06-23 04:51



Cuando se cambia la AssemblyVersion de una asamblea, Si tiene un nombre seguro, los ensamblados de referencia deben recompilarse; de ​​lo contrario, el ensamblaje no se carga. Si no tiene un nombre seguro, si no se agrega explícitamente al archivo de proyecto, no se copiará en el directorio de salida cuando se compile, por lo que puede omitir los ensamblados, especialmente después de limpiar el directorio de salida.


2
2018-02-17 05:21