Frage

Ich möchte, dass die Versionseigenschaft meiner Anwendung für jeden Build erhöht wird, bin mir aber nicht sicher, wie ich diese Funktionalität in Visual Studio (2005/2008) aktivieren kann.Ich habe versucht, die AssemblyVersion als 1.0.* anzugeben, aber es bringt mir nicht genau das, was ich will.

Ich verwende auch eine Einstellungsdatei und bei früheren Versuchen, als sich die Assembly-Version änderte, wurden meine Einstellungen auf die Standardeinstellungen zurückgesetzt, da die Anwendung in einem anderen Verzeichnis nach der Einstellungsdatei gesucht hat.

Ich möchte in der Lage sein, eine Versionsnummer in der Form 1.1.38 anzuzeigen, damit ich, wenn ein Benutzer ein Problem findet, die von ihm verwendete Version protokollieren und ihn auffordern kann, ein Upgrade durchzuführen, wenn er eine alte Version hat.

Eine kurze Erläuterung, wie die Versionierung funktioniert, wäre ebenfalls willkommen.Wann werden die Build- und Revisionsnummer erhöht?

War es hilfreich?

Lösung

Mit den „integrierten“ Dingen ist das nicht möglich, da die Verwendung von 1.0.* oder 1.0.0.* die Revisions- und Build-Nummern durch einen codierten Datums-/Zeitstempel ersetzt, was normalerweise auch eine gute Möglichkeit ist.

Weitere Informationen finden Sie unter Assembly-Linker Dokumentation im /v-Tag.

Um Zahlen automatisch zu erhöhen, verwenden Sie die AssemblyInfo-Aufgabe:

AssemblyInfo-Aufgabe

Dies kann so konfiguriert werden, dass die Build-Nummer automatisch erhöht wird.

Es gibt 2 Fallstricke:

  1. Jede der 4 Zahlen in der Versionszeichenfolge ist auf 65535 begrenzt.Dies ist eine Windows-Einschränkung und wird wahrscheinlich nicht behoben.
  2. Die Verwendung von with mit Subversion erfordert eine kleine Änderung:

Das Abrufen der Versionsnummer ist dann ganz einfach:

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

Und zur Klarstellung:In .net oder zumindest in C# ist der Build tatsächlich die DRITTE Nummer, nicht die vierte, wie manche Leute (zum Beispiel Delphi-Entwickler, die an Major.Minor.Release.Build gewöhnt sind) vielleicht erwarten.

In .net ist es Major.Minor.Build.Revision.

Andere Tipps

VS.NET setzt die Assembly-Version standardmäßig auf 1.0.* und verwendet beim automatischen Inkrementieren die folgende Logik:Es setzt den Build-Teil auf die Anzahl der Tage seit dem 1. Januar 2000 und den Revisionsteil auf die Anzahl der Sekunden seit Mitternacht, Ortszeit, geteilt durch zwei.Sieh dir das an MSDN-Artikel.

Die Assembly-Version befindet sich in einer Datei „assemblyinfo.vb“ oder „assemblyinfo.cs“.Aus der Datei:

' 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")> 

Ich habe festgestellt, dass es gut funktioniert, einfach das Datum des letzten Builds anzuzeigen, indem man überall dort verwendet, wo eine Produktversion benötigt wird:

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

Anstatt zu versuchen, die Version wie folgt abzurufen:

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

Welches Quellcodeverwaltungssystem verwenden Sie?

Fast alle verfügen über eine Art $ Id $-Tag, das beim Einchecken der Datei erweitert wird.

Normalerweise verwende ich irgendeine Form von Hackerangriffen, um dies als Versionsnummer anzuzeigen.

Die andere Alternative besteht darin, das Datum als Build-Nummer zu verwenden:080803-1448

[Visual Studio 2017, .csproj Eigenschaften]

Um Ihre PackageVersion/Version/AssemblyVersion-Eigenschaft (oder eine andere Eigenschaft) automatisch zu aktualisieren, erstellen Sie zunächst eine neue Microsoft.Build.Utilities.Task Klasse, die Ihre aktuelle Build-Nummer erhält und die aktualisierte Nummer zurücksendet (ich empfehle, ein separates Projekt nur für diese Klasse zu erstellen).

Ich aktualisiere die Major.Minor-Nummern manuell, aber lasse MSBuild die Build-Nummer automatisch aktualisieren (1.1.1).1, 1.1.2, 1.1.3, usw.:) :)

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

}

Rufen Sie dann Ihren kürzlich erstellten Task on MSBuild-Prozess auf und fügen Sie den nächsten Code in Ihrer .csproj-Datei hinzu:

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

Wenn Sie die Projektoption „Visual Studio Pack“ auswählen (ändern Sie einfach zu BeforeTargets="Build" zum Ausführen der Aufgabe vor Build) wird der RefreshVersion-Code ausgelöst, um die neue Versionsnummer zu berechnen, und XmlPoke Die Aufgabe aktualisiert Ihre .csproj-Eigenschaft entsprechend (ja, die Datei wird geändert).

Wenn ich mit NuGet-Bibliotheken arbeite, sende ich das Paket auch an das NuGet-Repository, indem ich einfach die nächste Build-Aufgabe zum vorherigen Beispiel hinzufüge.

<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 Hier habe ich den NuGet-Client (denken Sie daran, Ihren NuGet-API-Schlüssel durch Aufrufen zu speichern nuget SetApiKey <my-api-key> oder um den Schlüssel in den NuGet-Push-Aufruf aufzunehmen).

Nur für den Fall, dass es jemandem hilft ^_^.

Vor einiger Zeit habe ich eine schnelle und schmutzige Exe geschrieben, die die Versionsnummern in einer Assemblyinfo aktualisieren würde.{cs/vb} - Ich habe auch rxfind.exe (ein einfaches und leistungsstarkes Regex-basiertes Such-Ersetzungs-Tool) verwendet, um das zu tun Aktualisierung über eine Befehlszeile als Teil des Build-Prozesses.Noch ein paar hilfreiche Hinweise:

  1. Unterteilen Sie die Baugruppeninformationen in Produktteile (Firmenname, Version usw.) und baugruppenspezifische Teile (Baugruppenname usw.).Sehen Hier
  2. Außerdem verwende ich Subversion, daher fand ich es hilfreich, die Build-Nummer auf die Revisionsnummer von Subversion zu setzen, wodurch es wirklich einfach wird, immer zu der Codebasis zurückzukehren, die die Assembly generiert hat (z. B.1.4.100.1502 wurde ab Revision 1502 erstellt.

Wenn Sie eine automatisch inkrementierende Nummer wünschen, die bei jeder Kompilierung aktualisiert wird, können Sie diese verwenden VersionUpdater von einem Pre-Build-Event.Wenn Sie möchten, kann Ihr Pre-Build-Event die Build-Konfiguration überprüfen, sodass die Versionsnummer beispielsweise nur für einen Release-Build erhöht wird.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top