548 votes

Comment avoir un numéro de version auto incrémenté (Visual Studio) ?

Je veux stocker un ensemble d'entiers qui sont auto-incrémentés au moment de la construction :

int MajorVersion = 0;
int MinorVersion = 1;
int Revision = 92;

Lorsque je compile, Revision serait auto-incrémenté. Lorsque je construis le projet d'installation, MinorVersion serait incrémenté (je suis d'accord de le faire manuellement). MajorVersion serait incrémenté manuellement.

Ensuite, je pourrais afficher un numéro de version dans le menu Aide/A propos à l'utilisateur comme suit :

  Version : 0.1.92

Comment cela peut-il être réalisé ?

Cette question ne demande pas seulement comment avoir un numéro de version auto-incrémenté, mais aussi comment l'utiliser dans le code, ce qui est une réponse plus complète que les autres.

2 votes

Malgré que la question ait déjà reçu une réponse, les réponses de Noel Kennedy et Matthieu sont plus utiles que les autres questions/réponses

703voto

Noel Kennedy Points 4741

Si vous ajoutez une classe AssemblyInfo à votre projet et modifiez l'attribut AssemblyVersion pour se terminer par un astérisque, par exemple :

[assembly: AssemblyVersion("2.10.*")]

Visual Studio va augmenter le nombre final pour vous selon ces règles (merci galets, j'avais complètement tort!)

Pour faire référence à cette version dans le code, pour que vous puissiez l'afficher à l'utilisateur, utilisez la réflexion. Par exemple,

Version version = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
DateTime buildDate = new DateTime(2000, 1, 1)
                        .AddDays(version.Build).AddSeconds(version.Revision * 2);
string displayableVersion = $"{version} ({buildDate})";

Trois points importants à savoir

De @ashes999:

Il est également important de noter que si à la fois AssemblyVersion et AssemblyFileVersion sont spécifiés, vous ne verrez pas cela sur votre .exe.

De @BrainSlugs83:

Mettre seulement le 4e nombre à * peut être mauvais, car la version n'augmentera pas toujours. Le 3e nombre est le nombre de jours depuis l'année 2000, et le 4e nombre est le nombre de secondes depuis minuit (divisé par 2) [CE N'EST PAS ALÉATOIRE]. Donc si vous avez construit la solution tard dans une journée un jour, et tôt dans une journée le lendemain, la construction ultérieure aurait un numéro de version antérieur. Je recommande toujours d'utiliser X.Y.* au lieu de X.Y.Z.* car votre numéro de version augmentera TOUJOURS de cette manière.

Les nouvelles versions de Visual Studio donnent cette erreur :

(ce fil a commencé en 2009)

La chaîne de version spécifiée contient des caractères génériques, qui ne sont pas compatibles avec le déterminisme. Supprimez les caractères génériques de la chaîne de version, ou désactivez le déterminisme pour cette compilation.

Voir cette réponse SO qui explique comment supprimer le déterminisme (https://stackoverflow.com/a/58101474/1555612)

58 votes

Il convient également de noter que si à la fois AssemblyVersion et AssemblyFileVersion sont spécifiés, vous ne les verrez pas sur votre .exe.

171 votes

Définir uniquement le quatrième nombre comme étant " * " peut être mauvais, car la version n'augmentera pas toujours. Le troisième nombre est le nombre de jours depuis l'an 2000, et le quatrième nombre est le nombre de secondes depuis minuit (divisé par 2) [CE N'EST PAS ALÉATOIRE]. Ainsi, si vous avez construit la solution tard un jour, et tôt le lendemain, la construction ultérieure aurait un numéro de version antérieur. Je recommande d'utiliser toujours " X.Y.* " au lieu de " X.Y.Z.* " car votre numéro de version augmentera TOUJOURS de cette manière (à moins que vous ne compiliez du code à l'intérieur de votre TARDIS -- dans ce cas, puis-je venir ?).

4 votes

Pouvons-nous définir à quelle valeur commence l'astérisque (*)? Au lieu d'utiliser le nombre de jours depuis l'an 2000?

191voto

Robert Lewis Points 332

Vous pouvez utiliser le mécanisme de modélisation T4 dans Visual Studio pour générer le code source requis à partir d'un simple fichier texte :

Je voulais configurer la génération d'informations de version pour certains projets .NET. Cela fait longtemps que j'ai cherché des options disponibles, donc j'ai cherché en espérant trouver une manière simple de le faire. Ce que j'ai trouvé ne semblait pas très encourageant : les gens écrivent des extensions Visual Studio et des tâches personnalisées MsBuild juste pour obtenir un nombre entier (d'accord, peut-être deux). Cela semblait excessif pour un petit projet personnel.

L'inspiration est venue d'une des discussions StackOverflow où quelqu'un a suggéré que les modèles T4 pourraient faire le travail. Et bien sûr, ils le peuvent. La solution nécessite un effort minimal et aucune personnalisation de Visual Studio ou du processus de construction. Voici ce qu'il faut faire :

  1. Créer un fichier avec l'extension ".tt" et y placer un modèle T4 qui générera les attributs AssemblyVersion et AssemblyFileVersion :
<#@ template language="C#" #>
// 
// Ce code a été généré par un outil. Toute modification faite manuellement sera perdue
// la prochaine fois que ce code sera régénéré.
// 

using System.Reflection;

[assembly: AssemblyVersion("1.0.1.<#= this.RevisionNumber #>")]
[assembly: AssemblyFileVersion("1.0.1.<#= this.RevisionNumber #>")]
<#+
    int RevisionNumber = (int)(DateTime.UtcNow - new DateTime(2010,1,1)).TotalDays;
#>

Vous devrez décider de l'algorithme de génération du numéro de version. Pour moi, il suffisait de générer automatiquement un numéro de révision qui est défini comme le nombre de jours depuis le 1er janvier 2010. Comme vous pouvez le voir, la règle de génération de version est écrite en C# simple, vous pouvez donc facilement l'adapter à vos besoins.

  1. Le fichier ci-dessus doit être placé dans l'un des projets. J'ai créé un nouveau projet avec seulement ce fichier pour rendre la technique de gestion des versions claire. Lorsque je construis ce projet (en fait je n'ai même pas besoin de le construire : sauvegarder le fichier suffit à déclencher une action Visual Studio), le code C# suivant est généré :
// 
// Ce code a été généré par un outil. Toute modification faite manuellement sera perdue
// la prochaine fois que ce code sera régénéré.
// 

using System.Reflection;

[assembly: AssemblyVersion("1.0.1.113")]
[assembly: AssemblyFileVersion("1.0.1.113")]

Oui, aujourd'hui nous sommes à 113 jours depuis le 1er janvier 2010. Demain, le numéro de révision changera.

  1. La prochaine étape consiste à supprimer les attributs AssemblyVersion et AssemblyFileVersion du fichier AssemblyInfo.cs dans tous les projets qui devraient partager les mêmes informations de version générées automatiquement. Au lieu de cela, choisissez "Ajouter un élément existant" pour chaque projet, naviguez vers le dossier contenant le fichier de modèle T4, sélectionnez le fichier ".cs" correspondant et ajoutez-le en tant que lien. C'est tout !

Ce que j'aime dans cette approche, c'est qu'elle est légère (pas de tâches personnalisées MsBuild), et les informations de version générées automatiquement ne sont pas ajoutées au contrôle de source. Et bien sûr, l'utilisation de C# pour l'algorithme de génération de version ouvre la voie à des algorithmes de toute complexité.

3 votes

Je pense que c'est une excellente solution car elle offre la flexibilité des modules complémentaires et des exécutables personnalisés, mais c'est une solution purement prête à l'emploi de Visual Studio.

1 votes

A bien fonctionné pour mes besoins, en utilisant bzr revno pour peupler une partie des informations de version

12 votes

Cela fonctionne également très bien pour générer un jeton de cache spécifique à la construction pour les références JS et CSS.

32voto

gideon Points 12241

Si vous mettez un astérisque pour la construction et la révision, Visual Studio utilise le nombre de jours depuis le 1er janvier 2000 comme numéro de build et le nombre de secondes depuis minuit divisé par 2 comme révision.

Une solution bien meilleure et très pratique est http://autobuildversion.codeplex.com/

Cela fonctionne à merveille et c'est TRÈS flexible.

1 votes

Ne fonctionne pas dans VS2013.

0 votes

Merci pour l'explication - j'essayais de comprendre pourquoi le numéro de version n'augmentait pas (le même jour) sans regarder le numéro de révision. Cela l'explique, merci.

22voto

galets Points 4119

Voici la citation sur AssemblyInfo.cs de MSDN:

Vous pouvez spécifier toutes les valeurs ou accepter le numéro de build par défaut, le numéro de révision, ou les deux en utilisant un astérisque (). Par exemple, [assembly:AssemblyVersion("2.3.25.1")] indique 2 comme version majeure, 3 comme version mineure, 25 comme numéro de build, et 1 comme numéro de révision. Un nombre de version tel que [assembly:AssemblyVersion("1.2.")] spécifie 1 comme version majeure, 2 comme version mineure, et accepte les numéros de build et de révision par défaut. Un nombre de version tel que [assembly:AssemblyVersion("1.2.15.*")] spécifie 1 comme version majeure, 2 comme version mineure, 15 comme numéro de build, et accepte le numéro de révision par défaut. Le numéro de build par défaut augmente quotidiennement. Le numéro de révision par défaut est aléatoire.

Cela signifie essentiellement que si vous mettez un 1.1.* dans les informations d'assembly, seul le numéro de build s'incrémentera automatiquement, et cela ne se produira pas après chaque build, mais quotidiennement. Le numéro de révision changera à chaque build, mais de manière aléatoire, plutôt que de manière incrémentielle.

Ceci est probablement suffisant pour la plupart des cas d'utilisation. Si ce n'est pas ce que vous recherchez, vous êtes obligé d'écrire un script qui augmentera automatiquement le numéro de version lors de l'étape pré-build.

31 votes

Il s'incrémente de manière aléatoire? Ils se moquent de moi avec ça?

29 votes

Selon un commentaire laissé à msdn.microsoft.com/en-us/library/…, le numéro de révision n'est pas aléatoire, mais plutôt le nombre de secondes depuis minuit divisé par 2, ce qui, à mon avis, n'est pas si mal.

2 votes

Il existe une norme SemVer. Mais Microsoft, comme toujours, a son propre râteau.

16voto

Micah Smith Points 141

Utilisez AssemblyInfo.cs

Créez le fichier dans App_Code: et remplissez les informations suivantes ou utilisez Google pour d'autres possibilités d'attributs/propriétés.

AssemblyInfo.cs

using System.Reflection;

[assembly: AssemblyDescription("Des choses très utiles ici.")]
[assembly: AssemblyCompany("nomdelasociete")]
[assembly: AssemblyCopyright("Droits d'auteur © moi 2009")]
[assembly: AssemblyProduct("Produit soigné")]
[assembly: AssemblyVersion("1.1.*")]

Version de l'assembly étant la partie que vous recherchez vraiment.

Ensuite, si vous travaillez sur un site web, dans n'importe quelle page aspx, ou contrôle, vous pouvez ajouter dans la balise , ce qui suit:

CompilerOptions="\App_Code\AssemblyInfo.cs"

(remplacez le dossier avec la variable appropriée bien sûr).

Je ne crois pas que vous ayez besoin d'ajouter des options de compilateur de quelque manière que ce soit pour d'autres classes; toutes celles dans App_Code devraient recevoir les informations de version lorsqu'elles sont compilées.

J'espère que cela vous aidera.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X