Quelle est la meilleure façon d'utiliser les attributs de versioning d'assembly?

Question

Le AssemblyVersion et Les attributs AssemblyFileVersion sont la manière intégrée de gérer les numéros de version. Assemblages NET. Bien que le framework permette de déterminer automatiquement les parties les moins significatives d’un numéro de version (construction et révision, en termes de Microsoft), je trouve la méthode assez faible, et j'en ai certainement beaucoup d’autres.

J'aimerais donc vous demander de quelle manière on a décidé de faire en sorte que les numéros de version reflètent mieux la version réelle d'un projet? Avez-vous un script de pré-génération qui définit une partie de la version avec la date et l'heure, ou la version du référentiel pour votre copie de travail d'un projet? Utilisez-vous simplement la génération automatique fournie par le framework? Ou autre chose? Quelle est la meilleure façon de gérer la gestion des versions d'assemblages / fichiers?

Answer 1

Sur mon projet actuel, nous utilisons le numéro de révision Subversion comme la partie la moins significative (la version) du numéro de version, et nous utilisons un script Nant pour créer le fichier AssemblyInfo du projet. Nous utilisons le même numéro de version pour les attributs AssemblyVersion et AssemblyFileVersion. (Les trois autres parties sont major.minor.point, où major.minor sera incrémenté à chaque modification du schéma de base de données et le point est incrémenté pour chaque version.)

Nous avons commencé par simplement incrémenter le numéro de build, mais cela nécessitait que le fichier de version soit archivé pour chaque build et provoquait des conflits lors de la fusion. Lorsque cela s'est révélé impossible, nous avons commencé à utiliser CruiseControl.NET pour générer le numéro de version, mais il était difficile de reproduire manuellement des versions spécifiques. Finalement, nous sommes passés au schéma actuel (Subversion-revision).

Remarque: Malheureusement, avec .NET, il n'est pas possible de recréer parfaitement une version d'une révision précédente, car les compilateurs .NET encodent l'horodatage actuel dans le fichier objet lors de la compilation. Chaque fois que vous compilez le même code, vous obtenez un fichier objet différent.

Answer 2

Je vois ici beaucoup d'articles sur l'utilisation du numéro de révision de subversion en tant que composant de la version de l'assembly. Attention: les 4 numéros de version disponibles dans Windows (abcd) sont limités à 16 bits (max = 65535). Le numéro de révision de subversion peut facilement dépasser cette limite, surtout si vous hébergez plusieurs projets de la même manière. référentiel.

Answer 3

Lors d’un travail précédent, où nous utilisions Subversion, j’avais un script nant exécuté sur ccnet pour extraire la version du référentiel et l’utilisait comme numéro final.

Pour ce travail, nous utilisons VSS (obturateur). Ce n'est donc pas vraiment une option. Nous avons donc pour politique de le mettre à jour manuellement, avec les instructions suivantes:

• Majeur: modifications (> 25%) importantes de fonctionnalités ou d'interface.
• Minor: modifications ou ajouts mineurs dans les fonctionnalités ou l'interface.
• Construction: modifications mineures qui cassent l'interface.
• Révision: correction d’une construction qui ne change pas l’interface.

Nous conservons également l’Assemblée & amp; les versions du fichier synchronisées. La version d'Assembly peut être facilement lue par programme, tandis que la version du fichier peut être affichée sous forme de colonne en mode Détails dans l'Explorateur Windows.

Answer 4

Nos scripts de génération injectent le numéro de jeu de modifications de TFS dans la version. De cette façon, nous savons exactement quels archivages sont dans la construction.

Answer 5

Notre serveur de génération CruiseControl.NET a incorporé le numéro de liste de modifications obligatoire dans la AssemblyFileVersion - cela nous permet de rechercher le code source de tout assemblage créé par le serveur de génération. (Nous construisons toujours à partir de la branche principale.)

Pour les assemblages auxquels les clients feront référence, nous laissons la constante AssemblyVersion sauf en cas de modifications importantes. Dans ce cas, nous incrémentons la version pour nous assurer que le code client est reconstruit avec la nouvelle version.

Answer 6

Nous utilisons le versioning de Subversion et demandons aux buildscripts de mettre à jour les informations de version de l'assembly. Par conséquent, les contrôles de source contrôlent le contrôle de version.

Answer 7

Nous avons tendance à intégrer la date de publication (ou de génération) dans l'assemblage. Par exemple, si elle est construite aujourd'hui, la version serait "2008.10.06". (le script de construction le met à jour).

Answer 8

AssemblyVersionAttribute fait partie de l'identité d'un assembly. Changer cela signifie qu'il s'agit d'un assemblage différent et que les programmes liant cet assemblage doivent être recompilés / liés ou qu'une stratégie de version doit être appliquée. Nous n’avons pas trouvé cela intéressant, nous avons donc choisi d’augmenter uniquement AssemblyFileVersion pour chaque correctif et de ne modifier que AssemblyVersion pour chaque version majeure. Nous sommes conscients que cette décision ramène une partie de l’enfer de la win32 dll. Nous augmentons AssemblyFileVersion pour chaque construction et étiquetons / balançons le système de contrôle de version avec cette version afin de savoir de quelle source provient le fichier binaire.