c# visual Mettre à jour automatiquement le numéro de version




vsts auto increment build number (6)

Je souhaite que la propriété version de mon application soit incrémentée pour chaque génération, mais je ne suis pas sûr de savoir comment activer cette fonctionnalité dans Visual Studio (2005/2008). J'ai essayé de spécifier le AssemblyVersion comme 1.0. * Mais il ne me comprends pas exactement ce que je veux.

J'utilise également un fichier de paramètres et dans les tentatives antérieures lorsque la version de l'ensemble a changé mes paramètres ont été réinitialisés à la valeur par défaut depuis que l'application a cherché le fichier de paramètres dans un autre répertoire.

Je voudrais être en mesure d'afficher un numéro de version sous la forme de 1.1.38 donc quand un utilisateur trouve un problème, je peux enregistrer la version qu'ils utilisent ainsi que leur dire de mettre à niveau s'ils ont une ancienne version.

Une brève explication de la façon dont le travail de version serait également apprécié. Quand le numéro de build et de révision est-il incrémenté?


Avec le contenu "Built in", vous ne pouvez pas, en utilisant 1.0. * Ou 1.0.0. *, Remplacer les numéros de révision et de compilation par une date / horodatage codée, ce qui est généralement aussi un bon moyen.

Pour plus d'informations, reportez-vous à la documentation Assembly Linker dans la balise / v.

En ce qui concerne l'incrémentation automatique des nombres, utilisez la tâche AssemblyInfo:

Tâche AssemblyInfo

Cela peut être configuré pour incrémenter automatiquement le numéro de build.

Il y a 2 Gotchas:

  1. Chacun des 4 nombres de la chaîne Version est limité à 65535. Il s'agit d'une limitation Windows et il est peu probable qu'elle soit corrigée.
  2. Utiliser avec avec Subversion nécessite une petite modification:

Récupérer le numéro de version est alors assez facile:

Version v = Assembly.GetExecutingAssembly().GetName().Version;
string About = string.Format(CultureInfo.InvariantCulture, @"YourApp Version {0}.{1}.{2} (r{3})", v.Major, v.Minor, v.Build, v.Revision);

Et, pour clarifier: In .net ou au moins en C #, la construction est en fait le troisième numéro, pas le quatrième comme certaines personnes (par exemple Delphi Developers qui sont habitués à Major.Minor.Release.Build) peuvent s'attendre.

En .net, c'est Major.Minor.Build.Revision.


[Visual Studio 2017, propriétés .csproj ]

Pour mettre automatiquement à jour votre propriété PackageVersion / Version / AssemblyVersion (ou toute autre propriété), créez d'abord une nouvelle classe Microsoft.Build.Utilities.Task qui recevra votre numéro de build actuel et renverra le numéro mis à jour (je recommande de créer un autre projet juste pour cette classe).

Je mets à jour manuellement les numéros major.minor, mais laisse MSBuild mettre à jour automatiquement le numéro de build (1.1.1, 1.1.2, 1.1.3, etc.)

using Microsoft.Build.Framework;
using System;
using System.Collections.Generic;
using System.Text;

public class RefreshVersion : Microsoft.Build.Utilities.Task
{
    [Output]
    public string NewVersionString { get; set; }
    public string CurrentVersionString { get; set; } 

    public override bool Execute()
    {       
        Version currentVersion = new Version(CurrentVersionString ?? "1.0.0");

        DateTime d = DateTime.Now;
        NewVersionString = new Version(currentVersion.Major, 
            currentVersion.Minor, currentVersion.Build+1).ToString();
        return true;
    }

}

Ensuite, appelez votre processus Task on MSBuild récemment créé en ajoutant le code suivant sur votre fichier .csproj:

<Project Sdk="Microsoft.NET.Sdk">    
...
<UsingTask TaskName="RefreshVersion" AssemblyFile="$(MSBuildThisFileFullPath)\..\..\<dll path>\BuildTasks.dll" />
<Target Name="RefreshVersionBuildTask" BeforeTargets="Pack" Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
   <RefreshVersion CurrentVersionString="$(PackageVersion)">
          <Output TaskParameter="NewVersionString" PropertyName="NewVersionString" />             
   </RefreshVersion>
   <Message Text="Updating package version number to $(NewVersionString)..." Importance="high" />
   <XmlPoke XmlInputPath="$(MSBuildProjectDirectory)\mustache.website.sdk.dotNET.csproj" Query="/Project/PropertyGroup/PackageVersion" Value="$(NewVersionString)" />
</Target>
...
<PropertyGroup>
 ..
 <PackageVersion>1.1.4</PackageVersion>
 ..

Lorsque vous choisissez l'option projet Visual Studio Pack (il suffit de passer à BeforeTargets="Build" pour exécuter la tâche avant Build), le code RefreshVersion sera déclenché pour calculer le nouveau numéro de version, et la tâche XmlPoke mettra à jour votre propriété .csproj modifiera le fichier).

Lorsque je travaille avec des bibliothèques NuGet, j'envoie également le paquet au référentiel NuGet en ajoutant simplement la tâche de compilation suivante à l'exemple précédent.

<Message Text="Uploading package to NuGet..." Importance="high" />
<Exec WorkingDirectory="$(MSBuildProjectDirectory)\bin\release" Command="c:\nuget\nuget push *.nupkg -Source https://www.nuget.org/api/v2/package" IgnoreExitCode="true" />

c:\nuget\nuget est où j'ai le client NuGet (n'oubliez pas d'enregistrer votre clé API NuGet en appelant nuget SetApiKey <my-api-key> ou d'inclure la clé dans l'appel push de NuGet).

Juste au cas où ça aiderait quelqu'un ^ _ ^.


Quel système de contrôle de source utilisez-vous?

Presque tous ont une forme de $ Id $ tag qui se développe quand le fichier est archivé.

J'utilise généralement une forme de hackery pour l'afficher comme numéro de version.

L'autre alternative est l'utilisation de la date comme numéro de build: 080803-1448


Il y a quelque temps, j'ai écrit un exe rapide et sale qui mettrait à jour le numéro de la version dans un assemblyinfo. {Cs / vb} - J'ai aussi utilisé rxfind.exe (un outil de remplacement de recherche regex simple et puissant) pour faire mise à jour à partir d'une ligne de commande dans le cadre du processus de construction. Quelques autres conseils utiles:

  1. sépare l'assemblyinfo en parties de produits (nom de l'entreprise, version, etc.) et en pièces spécifiques à l'assemblage (nom de l'assemblage, etc.). Voir here
  2. Aussi - j'utilise subversion, j'ai donc trouvé utile de définir le numéro de version sur le numéro de révision de subversion, rendant ainsi très facile de revenir à la base de code qui a généré l'assembly (par exemple 1.4.100.1502 a été construit à partir de la révision 1502).

J'ai trouvé que cela fonctionne bien d'afficher simplement la date de la dernière construction en utilisant ce qui suit partout où une version du produit est nécessaire:

System.IO.File.GetLastWriteTime(System.Reflection.Assembly.GetExecutingAssembly().Location).ToString("yyyy.MM.dd.HH.mm.ss")

Plutôt que d'essayer d'obtenir la version de quelque chose comme ceci:

System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
object[] attributes = assembly.GetCustomAttributes(typeof(System.Reflection.AssemblyFileVersionAttribute), false);
object attribute = null;

if (attributes.Length > 0)
{
    attribute = attributes[0] as System.Reflection.AssemblyFileVersionAttribute;
}

Si vous souhaitez un numéro d'incrémentation automatique qui se met à jour chaque fois qu'une compilation est effectuée, vous pouvez utiliser VersionUpdater partir d'un événement de pré-génération. Votre événement de pré-construction peut vérifier la configuration de construction si vous préférez, afin que le numéro de version ne soit incrémenté que pour une version Release (par exemple).





versioning