Aggiorna automaticamente il numero di versione

Vorrei che la proprietà della versione della mia applicazione venisse incrementata per ogni build, ma non sono sicuro di come abilitare questa funzionalità in Visual Studio (2005/2008). Ho provato a specificare AssemblyVersion come 1.0. * Ma non mi ottiene esattamente quello che voglio.

Sto anche usando un file delle impostazioni e nei tentativi precedenti, quando la versione dell'assembly cambiava, le mie impostazioni venivano ripristinate ai valori predefiniti poiché l'applicazione cercava il file delle impostazioni in un'altra directory.

Vorrei essere in grado di visualizzare un numero di versione sotto forma di 1.1.38 così quando un utente trova un problema posso registrare la versione che sta usando e dirgli di aggiornare se ha una vecchia versione.

Sarebbe apprezzata anche una breve spiegazione di come funziona il controllo delle versioni. Quando vengono incrementati il ​​numero di build e revisione?

Con le cose "Built in", non puoi, poiché usare 1.0. * O 1.0.0. * Sostituirà la revisione e i numeri di build con una data / ora codificata, che di solito è anche un buon modo.

Per ulteriori informazioni, vedere la documentazione di Assembly Linker nel tag / v.

Per quanto riguarda l'incremento automatico dei numeri, utilizzare l'attività AssemblyInfo:

Attività AssemblyInfo

Questo può essere configurato per incrementare automaticamente il numero di build.

Ci sono 2 trucchi:

1. Ciascuno dei 4 numeri nella stringa della versione è limitato a 65535. Questa è una limitazione di Windows ed è improbabile che venga risolta.
   • Perché i numeri di build sono limitati a 65535?
2. L'utilizzo con Subversion richiede una piccola modifica:
   • Utilizzo di MSBuild per generare informazioni sulla versione dell'assembly in fase di compilazione (inclusa la correzione di SubVersion)

Il recupero del numero di versione è quindi abbastanza semplice:

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);

E, per chiarire: in .net o almeno in C #, la build è in realtà il TERZO numero, non il quarto come alcune persone (ad esempio sviluppatori Delphi che sono abituati a Major.Minor.Release.Build) potrebbero aspettarsi.

In .net, è Major.Minor.Build.Revision.

VS.NET imposta di default la versione Assembly su 1.0. * E utilizza la seguente logica durante l'incremento automatico: imposta la parte di build sul numero di giorni dal 1 ° gennaio 2000 e imposta la parte di revisione sul numero di secondi dalla mezzanotte, ora locale, divisa per due. Consulta questo articolo di MSDN .

La versione dell'assembly si trova in un file assemblyinfo.vb o assemblyinfo.cs. Dal file:

' Version information for an assembly consists of the following four values:
'
'      Major Version
'      Minor Version 
'      Build Number
'      Revision
'
' You can specify all the values or you can default the Build and Revision Numbers 
' by using the '*' as shown below:
' <Assembly: AssemblyVersion("1.0.*")> 

<Assembly: AssemblyVersion("1.0.0.0")> 
<Assembly: AssemblyFileVersion("1.0.0.0")> 

Ho scoperto che funziona bene visualizzare semplicemente la data dell'ultima build utilizzando quanto segue ogni volta che è necessaria una versione del prodotto:

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

Piuttosto che tentare di ottenere la versione da qualcosa di simile al seguente:

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;
}

Quale sistema di controllo del codice sorgente stai usando?

Quasi tutti hanno una qualche forma di tag $ Id $ che viene espansa quando il file viene archiviato.

Di solito uso una qualche forma di hackery per visualizzarlo come numero di versione.

L'altra alternativa è utilizzare la data come numero di build: 080803-1448

[Visual Studio 2017, proprietà .csproj ]

Per aggiornare automaticamente la proprietà PackageVersion / Version / AssemblyVersion (o qualsiasi altra proprietà), innanzitutto creare una nuova Microsoft.Build.Utilities.Taskclasse che otterrà il numero di build corrente e restituirà il numero aggiornato (consiglio di creare un progetto separato solo per quella classe).

Aggiorno manualmente i numeri major.minor, ma lascio che MSBuild aggiorni automaticamente il numero di build (1.1. 1 , 1.1. 2 , 1.1. 3 , ecc. :)

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;
    }

}

Quindi chiama la tua attività creata di recente nel processo MSBuild aggiungendo il codice successivo sul tuo file .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>
 ..

Quando si seleziona l'opzione del progetto Visual Studio Pack (basta passare a BeforeTargets="Build"per eseguire l'attività prima di Build), il codice RefreshVersion verrà attivato per calcolare il nuovo numero di versione e l' XmlPokeattività aggiornerà di conseguenza la proprietà .csproj (sì, modificherà il file).

Quando si lavora con le librerie NuGet, invio anche il pacchetto al repository NuGet semplicemente aggiungendo l'attività di compilazione successiva all'esempio precedente.

<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è dove ho il client NuGet (ricordarsi di salvare la chiave API NuGet chiamando nuget SetApiKey <my-api-key>o di includere la chiave nella chiamata push NuGet).

Nel caso in cui aiuti qualcuno ^ _ ^.

Qualche tempo fa ho scritto un exe veloce e sporco che aggiornava i numeri di versione in un assemblyinfo. {Cs / vb} - Ho anche usato rxfind.exe (un semplice e potente strumento di sostituzione di ricerca basato su regex) per eseguire aggiornamento da una riga di comando come parte del processo di compilazione. Un paio di altri suggerimenti utili:

1. separare le informazioni sull'assieme in parti del prodotto (nome dell'azienda, versione, ecc.) e parti specifiche dell'assieme (nome dell'assieme ecc.). Vedi qui
2. Inoltre, io uso subversion, quindi ho trovato utile impostare il numero di build sul numero di revisione di subversion, rendendo così davvero facile tornare sempre alla base di codice che ha generato l'assembly (ad esempio 1.4.100.1502 è stato compilato dalla revisione 1502).

Se desideri un numero con incremento automatico che si aggiorni ogni volta che viene completata una compilazione, puoi utilizzare VersionUpdater da un evento di pre-compilazione. Il tuo evento di pre-compilazione può controllare la configurazione della build, se preferisci, in modo che il numero di versione aumenti solo per una build di rilascio (ad esempio).