Quelles sont les différences entre AssemblyVersion, AssemblyFileVersion et AssemblyInformationalVersion?

Question

Il existe trois attributs de version d’assemblage. Quelles sont les différences? Puis-je utiliser AssemblyVersion et ignorer le reste?

MSDN dit:

• VersionVersion :

    

  Spécifie la version de l'assembly en cours d'attribution.

• AssemblyFileVersion :

    

  Demande à un compilateur d'utiliser un numéro de version spécifique pour la ressource de version de fichier Win32. La version du fichier Win32 ne doit pas nécessairement être identique au numéro de version de l'assembly.

• AssemblyInformationalVersion :

    

  Définit des informations de version supplémentaires pour un manifeste d'assembly.

Ceci est la suite de Quoi sont les meilleures pratiques pour utiliser les attributs d'assemblage?

Answer 1

VersionVersion

Où trouveront les assemblys faisant référence à votre assemblage. Si ce nombre change, les autres assemblys doivent mettre à jour leurs références dans votre assemblage! La AssemblyVersion est requise.

J'utilise le format: major.minor . Cela se traduirait par:

[assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Utilisé pour le déploiement. Vous pouvez augmenter ce nombre pour chaque déploiement. Il est utilisé par les programmes d'installation. Utilisez-le pour marquer les assemblys qui ont le même AssemblyVersion , mais sont générés à partir de versions différentes.

Sous Windows, il peut être visualisé dans les propriétés du fichier.

Si possible, laissez-le être généré par MSBuild. AssemblyFileVersion est facultatif. Si non spécifié, la version d'assemblage est utilisée.

J'utilise le format: major.minor.revision.build , où j'utilise une révision pour la phase de développement (Alpha, Bêta, RC et RTM), des service packs et des correctifs. Cela se traduirait par:

[assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

La version du produit de l'assemblage. C’est la version que vous utiliseriez pour parler à des clients ou pour l’affichage sur votre site Web. Cette version peut être une chaîne, comme " 1.0 Release Candidate ".

L'analyse de code s'en plaindra (CA2243) - signalé à Microsoft (non résolu dans VS2013).

La AssemblyInformationalVersion est facultative. Si non spécifié, AssemblyFileVersion est utilisé.

J'utilise le format: major.minor [révision sous forme de chaîne] . Cela se traduirait par:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

Answer 2

Le versionnage des assemblys dans .NET peut être une source de confusion, car il existe actuellement au moins trois façons de spécifier une version pour votre assemblage.

Voici les trois principaux attributs d'assembly liés à la version:

// 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")]

Par convention, les quatre parties de la version sont dénommées Version majeure , Version mineure , Construire et . Révision .

La AssemblyFileVersion est destinée à identifier de manière unique une construction de l’assemblage individuel

.

En règle générale, vous définissez manuellement les versions majeure et secondaire de AssemblyFileVersion pour refléter la version de l'assembly, puis vous augmentez la construction et / ou la révision à chaque fois que votre système de compilation compile l'assembly. AssemblyFileVersion devrait vous permettre d'identifier de manière unique une construction de l'assembly, de sorte que vous puissiez l'utiliser comme point de départ pour déboguer tous les problèmes.

Sur mon projet actuel, le serveur de construction code le numéro de la liste de modifications de notre référentiel de contrôle de source dans les parties Génération et Révision de AssemblyFileVersion. Cela nous permet de mapper directement d'un assemblage vers son code source, pour tout assemblage généré par le serveur de génération (sans avoir à utiliser d'étiquettes ou de branches dans le contrôle de code source, ni à conserver manuellement les enregistrements des versions publiées).

Ce numéro de version est stocké dans la ressource de version Win32 et peut être vu lors de l'affichage des pages de propriétés de l'Explorateur Windows pour l'assembly.

Le CLR ne s'intéresse pas à la version AssemblyFileVersion.

La AssemblyInformationalVersion est destinée à représenter la version de votre produit entier

AssemblyInformationalVersion est conçu pour permettre une gestion cohérente du produit dans son intégralité, qui peut consister en de nombreux assemblages indépendamment de la version, éventuellement avec des règles de gestion différentes, et potentiellement développés par des équipes disparates.

  

& # 8220; Par exemple, la version 2.0 d'un produit   peut contenir plusieurs assemblages; un   de ces assemblées est marqué comme   version 1.0 puisqu'il s'agit d'un nouvel assemblage   qui n’a pas été expédié dans la version 1.0 du logiciel   même produit. En règle générale, vous définissez la   parties majeures et mineures de cette version   nombre représentant la version publique   de votre produit. Ensuite, vous augmentez   les parties de construction et de révision à chaque fois   vous emballez un produit complet avec   toutes ses assemblées. & # 8221;              & # 8212; Jeffrey Richter, [CLR via C # (Deuxième édition)] p. 57

Le CLR ne s'intéresse pas à la version AssemblyInformationalVersion.

La AssemblyVersion est la seule version qui intéresse le CLR (mais elle se soucie de la totalité de AssemblyVersion )

AssemblyVersion est utilisé par le CLR pour se lier à des assemblys fortement nommés. Il est stocké dans la table de métadonnées du manifeste AssemblyDef de l’assemblage construit et dans la table AssemblyRef de tout assemblage qui y fait référence.

Cela est très important, car cela signifie que lorsque vous faites référence à un assemblage fortement nommé, vous êtes étroitement lié à une AssemblyVersion spécifique de cet assemblage. L'ensemble AssemblyVersion doit être une correspondance exacte pour que la liaison réussisse. Par exemple, si vous référencez la version 1.0.0.0 d'un assemblage fortement nommé au moment de la construction, mais que seule la version 1.0.0.1 de cet assemblage est disponible au moment de l'exécution, la liaison échouera! (Vous devrez alors contourner ce problème en utilisant Redirection des liaisons d'assemblage .)

Confusion quant à savoir si l'intégralité de AssemblyVersion doit correspondre. (Oui, c'est le cas.)

Il existe une petite confusion sur le point de savoir si la version complète de AssemblyVersion doit correspondre exactement pour qu'un assemblage soit chargé. Certaines personnes croient faussement que seules les parties majeure et mineure de AssemblyVersion doivent correspondre pour que la reliure réussisse. Cette hypothèse est judicieuse, mais elle est finalement incorrecte (à partir de .NET 3.5) et il est trivial de la vérifier pour votre version du CLR. Il suffit d'exécuter cet exemple de code .

Sur ma machine, le deuxième assemblage échoue et les deux dernières lignes du journal de fusion expliquent parfaitement pourquoi:

.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.

Je pense que la source de cette confusion est probablement due au fait que Microsoft avait initialement l'intention d'être un peu plus indulgent quant à cette correspondance stricte de la version complète de AssemblyVersion, en ne faisant correspondre que les parties de version majeure et mineure:

  

& # 8220; Lors du chargement d’un assemblage, le CLR recherche automatiquement la dernière   version de maintenance installée   correspond à la version majeure / mineure du   l'assemblage est demandé. & # 8221;               & # 8212; Jeffrey Richter, [CLR via C # (Deuxième édition)] p. 56

C’est ce qui se passait dans la version bêta 1 du CLR 1.0, mais cette fonctionnalité a été supprimée avant la version 1.0 et n’a pas réussi à refaire surface dans .NET 2.0:

  

& # 8220; Remarque: je viens de décrire comment vous   devrait penser aux numéros de version.   Malheureusement, le CLR ne traite pas   numéros de version de cette façon. [En .NET   2.0], le CLR considère un numéro de version comme une valeur opaque, et si un assemblage   dépend de la version 1.2.3.4 d'une autre   assemblage, le CLR tente de charger   version 1.2.3.4 uniquement (sauf si une liaison   la redirection est en place). cependant,    Microsoft envisage de modifier le   Le chargeur de CLR dans une future version afin de   qu'il charge le dernier   construction / révision pour une majeure / mineure donnée   version d'un assemblage . Par exemple,   sur une future version du CLR, si le   Le chargeur essaie de trouver la version   1.2.3.4 d’un assemblage et que la version 1.2.5.0 existe, le chargeur avec ramasse automatiquement la dernière   version de maintenance. Ce sera un très   Nous nous félicitons des modifications apportées au chargeur & # 8212; du CLR. je   car on ne peut pas attendre. & # 8221;               & # 8212; Jeffrey Richter, [CLR via C # (Deuxième édition)] p. 164 (accent mis   le mien)

Ce changement n'ayant toujours pas été mis en œuvre, je pense qu'il est prudent de supposer que Microsoft a fait écho à cette intention et qu'il est peut-être trop tard pour le modifier maintenant. J’ai essayé de chercher sur le Web pour savoir ce qui s’est passé avec ces plans, mais je n’ai pas pu trouver de réponse. Je voulais toujours aller au fond des choses.

J'ai donc envoyé un courriel à Jeff Richter pour lui demander directement & # 8212; Je pensais que si quelqu'un savait ce qui s'était passé, ce serait lui.

Il a répondu dans les 12 heures, pas plus tard qu'un samedi matin, et a précisé que le chargeur .NET 1.0 Beta 1 avait implémenté cette "# 8216; restauration automatique" & # 8217; mécanisme de récupération de la dernière version disponible d'un build et d'une révision d'assembly, mais ce comportement a été annulé avant la livraison de .NET 1.0. Il était ensuite prévu de réactiver cette fonctionnalité, mais elle n’a pas été livrée avant l’envoi du CLR 2.0. Puis vint Silverlight, qui était prioritaire pour l’équipe du CLR. Cette fonctionnalité a donc encore été retardée. Entre-temps, la plupart des personnes présentes à l'époque de CLR 1.0 Beta 1 ont depuis quitté la situation. Il est donc peu probable que cela se concrétise, malgré tout le travail difficile qui avait déjà été mis en elle.

Le comportement actuel, semble-t-il, est là pour rester.

Il est également intéressant de noter, d'après ma discussion avec Jeff, que AssemblyFileVersion n'a été ajouté qu'après la suppression du & # 8216; restauration automatique & # 8217; mécanisme & # 8212; car après la version 1.0 bêta 1, toute modification apportée à AssemblyVersion représentait un changement décisif pour vos clients: il n’y avait alors nulle part où stocker votre numéro de build en toute sécurité. AssemblyFileVersion est ce havre de paix, car il n’est jamais automatiquement examiné par le CLR. C’est peut-être plus clair ainsi, avec deux numéros de version distincts, avec des significations distinctes, plutôt que d’essayer de séparer les parties Majeure / Mineure (rupture) et Construire / Révision (non-rupture) de AssemblyVersion.

La ligne du bas: réfléchissez bien lorsque vous modifiez votre AssemblyVersion

La morale est que si vous envoyez des assemblages que d'autres développeurs vont référencer, vous devez faire très attention lorsque vous modifiez (et ne modifiez pas) la version AssemblyVersion de ces assemblys. Toute modification apportée à AssemblyVersion signifiera que les développeurs d'applications devront soit recompiler avec la nouvelle version (pour mettre à jour ces entrées AssemblyRef), soit utiliser des redirections de liaison d'assembly pour remplacer manuellement la liaison.

• Ne pas modifier la version d'assemblage pour une version de maintenance destinée à être rétrocompatible.
• Ne changez la version d'assemblage pour une version dont vous savez qu'elle présente des modifications radicales.

Il suffit de regarder à nouveau les attributs de version sur mscorlib:

<*>

Notez que c'est la AssemblyFileVersion qui contient toutes les informations de maintenance intéressantes (c'est la partie Révision de cette version qui vous indique le Service Pack sur lequel vous vous trouvez), mais la version de AssemblyVersion est corrigée. à un ennuyeux vieux 2.0.0.0. Toute modification apportée à AssemblyVersion obligerait chaque application .NET faisant référence à mscorlib.dll à se recompiler avec la nouvelle version!

Answer 3

AssemblyVersion reste à peu près interne à .NET, alors que AssemblyFileVersion correspond à ce que Windows voit. Si vous accédez aux propriétés d'un assemblage situé dans un répertoire et passez à l'onglet de version, AssemblyFileVersion correspond à ce que vous verrez en haut. Si vous triez les fichiers par version, c’est ce qui est utilisé par Explorer.

La AssemblyInformationalVersion est mappée à la " version du produit " et est destiné à être purement "utilisé par l'homme".

AssemblyVersion est certainement le plus important, mais je ne voudrais pas ignorer AssemblyFileVersion non plus. Si vous ne fournissez pas AssemblyInformationalVersion , le compilateur l'ajoute pour vous en supprimant le paramètre "révision". pièce de votre numéro de version et en laissant le major.minor.build.

Answer 4

AssemblyInformationalVersion et AssemblyFileVersion s'affichent lorsque vous affichez le " Version " informations sur un fichier via l'Explorateur Windows en affichant les propriétés du fichier. Ces attributs sont en fait compilés dans une ressource VERSION_INFO créée par le compilateur.

AssemblyInformationalVersion est la "version du produit". valeur. AssemblyFileVersion est la " Version du fichier " valeur.

La AssemblyVersion est spécifique aux assemblys .NET et est utilisée par le chargeur d'assemblées .NET pour savoir quelle version d'un assemblage à charger / lier à l'exécution.

Parmi ceux-ci, le seul qui soit absolument requis par .NET est l'attribut AssemblyVersion . Malheureusement, cela peut également causer le plus de problèmes quand il change sans distinction, surtout si vous nommez vos assemblys avec force.

Answer 5

Pour que cette question reste d'actualité, il convient de souligner que AssemblyInformationalVersion est utilisé par NuGet et reflète la version du package , y compris tout suffixe de pré-version.

Par exemple une AssemblyVersion 1.0.3. * fournie avec le noyau asp.net dotnet-cli

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

Produit un package avec la version 1.0.3-ci-7 que vous pouvez inspecter avec une réflexion en utilisant:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

Answer 6

Cela vaut la peine de noter quelques autres choses:

1) Comme indiqué dans la boîte de dialogue Propriétés de l'Explorateur Windows pour le fichier d'assemblage généré, il existe deux emplacements appelés "Version du fichier". Celui affiché dans l’en-tête de la boîte de dialogue affiche la version de montage, pas la version de fichier.

Dans la section Autres informations de version, il existe un autre élément appelé "Version du fichier". C’est ici que vous pouvez voir ce qui a été entré comme AssemblyFileVersion.

2) AssemblyFileVersion est juste du texte brut. Il n'est pas nécessaire qu'il soit conforme aux restrictions de schéma de numérotation imposées par AssemblyVersion (< build > < 65K, par exemple). Si vous le souhaitez, il peut s'agir de 3,2. & Lt; release tag text >. & Lt; datetime > ;, Votre système de construction devra remplir les jetons.

De plus, AssemblyVersion n’est pas soumis au caractère générique. Si vous n’avez que la valeur " 3.0.1. * & Quot; Dans AssemblyInfo.cs, c’est exactement ce qui apparaît dans l’élément Autre version - > Version du fichier.

3) Cependant, je ne connais pas l’impact sur un installateur de l’utilisation de numéros de version de fichier numériques, cependant.

Answer 7

Lorsque la version d'assemblage d'une assemblée est modifiée, S'il a un nom fort, les assemblages de référence doivent être recompilés, sinon l'assemblage ne se charge pas! S'il n'a pas de nom fort, s'il n'est pas explicitement ajouté au fichier de projet, il ne sera pas copié dans le répertoire de sortie lors de la génération, vous risqueriez ainsi de manquer les assemblys dépendants, en particulier après le nettoyage du répertoire de sortie.