Hola usuario de nuestro sitio, descubrimos la respuesta a tu interrogante, deslízate y la obtendrás más abajo.
Solución:
EnsamblajeVersión
Dónde buscarán otros ensamblajes que hagan referencia a su ensamblaje. Si este número cambia, otros ensamblajes deben actualizar sus referencias a su ensamblaje. Solo actualice esta versión si no es compatible con versiones anteriores. los AssemblyVersion es requerido.
Yo uso el formato: Mayor Menor. Esto daría como resultado:
[assembly: AssemblyVersion("1.0")]
Si está siguiendo SemVer estrictamente, esto significa que solo actualiza cuando el importante cambios, por lo que 1.0, 2.0, 3.0, etc.
AssemblyFileVersion
Se utiliza para la implementación. Puede aumentar este número para cada implementación. Lo utilizan los programas de instalación. Úselo para marcar ensamblajes que tengan el mismo AssemblyVersion, pero se generan a partir de diferentes versiones.
En Windows, se puede ver en las propiedades del archivo.
AssemblyFileVersion es opcional. Si no se proporciona, se utiliza AssemblyVersion.
Yo uso el formato: major.minor.patch.build, donde sigo SemVer para las primeras tres partes y uso el número de compilación del servidor de compilación para la última parte (0 para compilación local). Esto daría como resultado:
[assembly: AssemblyFileVersion("1.3.2.254")]
Tenga en cuenta que System.Version nombra estas partes como major.minor.build.revision!
MontajeInformacionalVersión
La versión del producto del ensamblaje. Esta es la versión que usaría cuando hablara con los clientes o para mostrarla en su sitio web. Esta versión puede ser una string, igual que ‘1.0 Release Candidate‘.
los AssemblyInformationalVersion es opcional. Si no se proporciona, se utiliza AssemblyFileVersion.
Yo uso el formato: Mayor Menor[.patch] [revision as string]. Esto daría como resultado:
[assembly: AssemblyInformationalVersion("1.0 RC1")]
El control de versiones de ensamblados en .NET puede ser una perspectiva confusa dado que actualmente hay al menos tres formas de especificar una versión para su ensamblado.
Aquí están los tres ensamblados principales relacionados con la versión attributes:
// 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 denominan Versión principal, Versión menor, Construir, y Revisión.
los AssemblyFileVersion tiene la intención de identificar de forma única una compilación del montaje individual
Por lo general, configurará manualmente la versión de archivo de ensamblaje principal y secundaria 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 ensamblaje. AssemblyFileVersion debería permitirle identificar de forma única una compilación del ensamblado, de modo que pueda usarlo como punto de partida para depurar 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 código fuente en las partes de compilación y revisión de AssemblyFileVersion. Esto nos permite mapear directamente desde un ensamblado 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 código fuente, o mantener manualmente los registros de las versiones publicadas).
Este número de versión se almacena en el recurso de versión de Win32 y se puede ver al ver las páginas de propiedades del Explorador de Windows para el ensamblaje.
A CLR no le importa ni examina AssemblyFileVersion.
los AssemblyInformationalVersion está destinado a representar la versión de todo su producto
La AssemblyInformationalVersion está pensada para permitir un control de versiones coherente de todo el producto, que puede constar de muchos ensamblados que tienen versiones independientes, tal vez con diferentes políticas de control de versiones, y potencialmente desarrollados por equipos dispares.
“Por ejemplo, la versión 2.0 de un producto puede contener varios ensamblajes; uno de estos ensamblajes está marcado como versión 1.0 ya que es un ensamblado nuevo que no se envió en la versión 1.0 del mismo producto. Normalmente, configura las partes principales y secundarias de este número de versión para representar la versión pública de su producto. Luego, incrementa las piezas de construcción y revisión cada vez que empaqueta un producto completo con todos sus ensamblajes “. – Jeffrey Richter, [CLR via C# (Second Edition)] pag. 57
A CLR no le importa ni examina AssemblyInformationalVersion.
los AssemblyVersion es la única versión que le importa a CLR (pero le importa todo el AssemblyVersion)
El CLR usa AssemblyVersion para enlazar a ensamblados con nombres seguros. Se almacena en la tabla de metadatos del manifiesto AssemblyDef del ensamblado compilado y en la tabla AssemblyRef de cualquier ensamblado que haga referencia a él.
Esto es muy importante, porque significa que cuando hace referencia a un ensamblado con un nombre seguro, está estrechamente vinculado a un AssemblyVersion específico de ese ensamblado. Toda la AssemblyVersion debe coincidir exactamente para que el enlace se realice correctamente. Por ejemplo, si hace referencia a la versión 1.0.0.0 de un ensamblado con un nombre seguro en el momento de la compilación, pero solo la versión 1.0.0.1 de ese ensamblado está disponible en el tiempo de ejecución, el enlace fallará. (A continuación, tendrá que solucionar este problema mediante la redirección de enlace de ensamblado).
Confusión sobre si todo AssemblyVersion tiene que coincidir. (Sí, lo hace).
Existe una pequeña confusión acerca de si la versión de ensamblaje completa debe coincidir exactamente para que se cargue un ensamblado. Algunas personas están bajo el false creencia de que solo las partes mayor y menor de AssemblyVersion deben 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 de CLR. Simplemente ejecute este código de muestra.
En mi máquina, la segunda carga de ensamblaje falla, y las dos últimas 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 = PhoenixDani
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:WindowsMicrosoft.NETFramework64v2.0.50727configmachine.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 la fuente de esta confusión se debe probablemente a que Microsoft originalmente tenía la intención de ser un poco más indulgente con esta estricta coincidencia de la versión completa de AssemblyVersion, al hacer coincidir solo las partes de la versión principal y secundaria:
“Al cargar un ensamblaje, CLR encontrará automáticamente la última versión de servicio instalada que coincida con la versión principal / secundaria del ensamblaje que se solicita”. – Jeffrey Richter, [CLR via C# (Second Edition)] pag. 56
Este fue el comportamiento en Beta 1 de 1.0 CLR, sin embargo, esta característica se eliminó antes de la versión 1.0 y no ha logrado reaparecer en .NET 2.0:
“Nota: acabo de describir cómo debería pensar en los números de versión. Desafortunadamente, CLR no trata los números de versión de esta manera. [In .NET
2.0], CLR trata un número de versión como un valor opaco, y si un ensamblado depende de la versión 1.2.3.4 de otro ensamblado, CLR intenta cargar solo la versión 1.2.3.4 (a menos que haya una redirección de enlace). Sin embargo,
Microsoft tiene planes de cambiar el cargador de CLR en una versión futura para que cargue la última versión / revisión para una versión mayor / menor determinada de un ensamblado.. Por ejemplo, en una versión futura de CLR, si el cargador está intentando encontrar la versión 1.2.3.4 de un ensamblado y existe la versión 1.2.5.0, el cargador recogerá automáticamente la última versión de servicio. Este será un cambio muy bienvenido en el cargador de CLR; por mi parte, no puedo esperar “. – Jeffrey Richter, [CLR via C# (Second Edition)] pag. 164 (énfasis mío)
Como este cambio aún no se ha implementado, creo que es seguro asumir que Microsoft ha retrocedido en esta intención, y 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.
Así que 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ó dentro de las 12 horas, un sábado por la mañana nada menos, y aclaró que el cargador .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 revirtió antes de que se enviara .NET 1.0. Más tarde se pretendió revivir esto, pero no lo logró 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 vivían en los días de CLR 1.0 Beta 1 han seguido adelante, por lo que es poco probable que esto vea la luz del día, a pesar de todo el arduo trabajo que ya se había realizado.
El comportamiento actual, al parecer, llegó 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 ‘avance automático’, porque después de 1.0 Beta 1, cualquier cambio en AssemblyVersion fue un cambio importante para sus clientes, luego hubo ningún lugar para almacenar de forma segura su número de compilación. AssemblyFileVersion es ese refugio seguro, ya que CLR nunca lo examina automáticamente. Tal vez sea más claro de esa manera, tener dos números de versión separados, con significados separados, en lugar de intentar hacer esa separación entre las partes Mayor / Menor (ruptura) y Compilación / Revisión (no ruptura) de AssemblyVersion.
El resultado final: Piense detenidamente cuando cambie su AssemblyVersion
La moraleja es que si está enviando ensamblados a los que otros desarrolladores van a hacer referencia, debe tener mucho cuidado cuando cambie (y no cambie) la versión de ensamblaje de esos ensamblajes. Cualquier cambio en AssemblyVersion significará que los desarrolladores de aplicaciones tendrán que volver a compilar con la nueva versión (para actualizar esas entradas de AssemblyRef) o usar redireccionamientos de enlace de ensamblado para anular manualmente el enlace.
- No cambie AssemblyVersion por una versión de servicio que esté destinada a ser compatible con versiones anteriores.
- Hacer cambie AssemblyVersion por una versión que sepa que tiene cambios importantes.
Solo eche otro vistazo a la versión attributes 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 AssemblyFileVersion la que contiene toda la información de servicio interesante (es la parte de Revisión de esta versión la que le indica en qué Service Pack se encuentra), mientras que AssemblyVersion está corregida en una aburrida versión 2.0.0.0. Cualquier cambio en AssemblyVersion obligaría a todas las aplicaciones .NET que hagan referencia a mscorlib.dll a volver a compilar con la nueva versión.
AssemblyVersion prácticamente permanece interno a .NET, mientras que AssemblyFileVersion es lo que ve Windows. Si va a las propiedades de un ensamblado que se encuentra en un directorio y cambia a la pestaña versión, la AssemblyFileVersion es lo que verá en la parte superior. 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 “para uso humano”.
AssemblyVersion es sin duda el más importante, pero no me saltaría AssemblyFileVersion, cualquiera. Si no proporciona AssemblyInformationalVersion, el compilador lo agrega eliminando la parte de “revisión” de su número de versión y dejando el major.minor.build.
Si aceptas, puedes dejar una reseña acerca de qué te ha parecido esta sección.