Wie kann ich die C # -Baugruppenversion über unsere CI-Plattform (Hudson) automatisch inkrementieren?

Ich und meine Gruppe sind entsetzlich darin, Versionsnummern für Baugruppen zu erhöhen, und wir versenden häufig Baugruppen mit Versionen 1.0.0.0. Offensichtlich verursacht dies viele Kopfschmerzen.

Wir werden mit unseren Praktiken über unsere CI- Plattform viel besser und ich möchte sie wirklich so einrichten, dass die Werte in der assemblyinfo.csDatei automatisch erhöht werden, damit die Versionen unserer Assemblys automatisch mit den Codeänderungen in dieser Assembly aktualisiert werden.

Ich hatte zuvor (bevor wir Hudson gefunden haben ) eine Möglichkeit eingerichtet, den Wert entweder über msbuilddie Befehlszeile oder über die Befehlszeile zu erhöhen (kann mich nicht erinnern), aber mit Hudson wird das SVN-Repository aktualisiert und ein weiterer Build ausgelöst. Dies würde zu einer langsamen Endlosschleife führen, da Hudson jede Stunde SVN abfragt.

Ist es eine schlechte Idee, wenn Hudson die Versionsnummer erhöht? Was wäre eine alternative Möglichkeit?

Im Idealfall wären meine Kriterien für eine Lösung eines:

• Erhöht die Build-Nummer assemblyinfo.csvor einem Build
• Erhöht nur die Build-Nummer in Assemblys, die sich geändert haben. Dies ist möglicherweise nicht möglich, da Hudson den Projektordner bei jedem Build löscht
• Überträgt die geänderte Assemblyinfo.cs in das Code-Repository (derzeit VisualSVN ).
• Bewirkt nicht, dass Hudson beim nächsten Scannen nach Änderungen einen neuen Build auslöst

Wenn ich das in meinem Kopf herausarbeite, könnte ich leicht eine Lösung für das meiste davon durch Batch-Dateien / Befehle finden, aber alle meine Ideen würden Hudson veranlassen, beim nächsten Scannen einen neuen Build auszulösen. Ich suche nicht jemanden, der alles für mich tut, sondern mich in die richtige Richtung weist, vielleicht eine Technik, mit der Hudson bestimmte SVN-Commits ignoriert usw.

Alles, was ich bisher gefunden habe, ist nur ein Artikel, in dem erklärt wird, wie die Versionsnummer automatisch erhöht wird. Nichts berücksichtigt eine CI-Plattform, die in eine Endlosschleife gesponnen werden könnte.

Eine einfache Alternative besteht darin, die C # -Umgebung die Assemblyversion für Sie erhöhen zu lassen, indem Sie das Versionsattribut auf setzen major.minor.*(wie in der AssemblyInfo-Dateivorlage beschrieben).

Möglicherweise suchen Sie jedoch nach einer umfassenderen Lösung.

EDIT (Antwort auf die Frage in einem Kommentar):

Von AssemblyInfo.cs:

// 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.*")]

Folgendes habe ich getan, um das AssemblyFileVersion-Attribut zu stempeln.

Die AssemblyFileVersion wurde aus AssemblyInfo.cs entfernt

Fügen Sie dem Projekt eine neue, leere Datei mit dem Namen AssemblyFileInfo.cs hinzu.

Installieren Sie das Toolset für MSBuild-Community-Aufgaben auf dem Hudson Build-Computer oder als NuGet-Abhängigkeit in Ihrem Projekt.

Bearbeiten Sie die Projektdatei (csproj), es ist nur eine msbuild-Datei, und fügen Sie Folgendes hinzu.

Irgendwo wird <PropertyGroup>die Version angegeben. Ändern Sie das so, dass es zB liest

 <Major>1</Major>
 <Minor>0</Minor>
 <!--Hudson sets BUILD_NUMBER and SVN_REVISION -->
 <Build>$(BUILD_NUMBER)</Build>
 <Revision>$(SVN_REVISION)</Revision>

Hudson stellt die env-Variablen bereit, die Sie dort sehen, wenn das Projekt auf Hudson erstellt wird (vorausgesetzt, es wird aus der Subversion abgerufen).

Fügen Sie am Ende der Projektdatei hinzu

 <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" />
  <Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')">
    <Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" />
    <AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " />
  </Target>

Dies verwendet die MSBuildCommunityTasks, um die AssemblyFileVersion.cs zu generieren und ein AssemblyFileVersion-Attribut einzuschließen, bevor das Projekt erstellt wird. Sie können dies für alle Versionsattribute tun, wenn Sie möchten.

Das Ergebnis ist, dass die resultierende Assembly jedes Mal, wenn Sie einen Hudson-Build ausgeben, eine AssemblyFileVersion von 1.0.HUDSON_BUILD_NR.SVN_REVISION erhält, z. B. 1.0.6.2632, was bedeutet, dass der 6. Build # in Hudson aus der Subversion-Revision 2632 stammt.

Hier ist eine elegante Lösung, die beim Hinzufügen eines neuen Projekts ein wenig Arbeit im Voraus erfordert, den Prozess jedoch sehr einfach abwickelt.

Die Idee ist, dass jedes Projekt mit einer Lösungsdatei verknüpft ist, die nur die Versionsinformationen der Baugruppe enthält. Ihr Erstellungsprozess muss also nur eine einzige Datei aktualisieren, und alle Assemblyversionen werden beim Kompilieren aus einer Datei abgerufen.

Schritte:

1. Fügen Sie Ihrer Lösungsdatei * .cs eine Klasse hinzu, die ich min SharedAssemblyProperties.cs genannt habe
2. Entfernen Sie alle cs-Informationen aus dieser neuen Datei
3. Schneiden Sie die Assembly-Informationen aus einer AssemblyInfo-Datei aus: [Assembly: AssemblyVersion ("1.0.0.0")] [Assembly: AssemblyFileVersion ("1.0.0.0")]
4. Fügen Sie die Anweisung "using System.Reflection;" in die Datei und fügen Sie dann Daten in Ihre neue cs-Datei ein (ex SharedAssemblyProperties.cs)
5. Fügen Sie Ihrem Projekt ein vorhandenes Element hinzu (warten Sie ... lesen Sie weiter, bevor Sie die Datei hinzufügen).
6. Wählen Sie die Datei aus und bevor Sie auf Hinzufügen klicken, klicken Sie auf die Dropdown-Liste neben der Schaltfläche Hinzufügen und wählen Sie "Als Link hinzufügen".
7. Wiederholen Sie die Schritte 5 und 6 für alle vorhandenen und neuen Projekte in der Lösung

Wenn Sie die Datei als Link hinzufügen, werden die Daten in der Projektdatei gespeichert und beim Kompilieren werden die Versionsinformationen der Baugruppe aus dieser einen Datei abgerufen.

In Ihrer Quellcodeverwaltung fügen Sie eine Bat-Datei oder eine Skriptdatei hinzu, die einfach die Datei SharedAssemblyProperties.cs erhöht, und alle Ihre Projekte aktualisieren ihre Assembly-Informationen aus dieser Datei.

Hudson kann so konfiguriert werden, dass Änderungen an bestimmten Pfaden und Dateien ignoriert werden, sodass kein neuer Build veranlasst wird.

Klicken Sie auf der Jobkonfigurationsseite unter Quellcodeverwaltung auf die Schaltfläche Erweitert . Im Feld Ausgeschlossene Regionen geben Sie einen oder mehrere reguläre Ausdrücke ein, um den Ausschlüssen zu entsprechen.

Um beispielsweise Änderungen an der Datei version.properties zu ignorieren, können Sie Folgendes verwenden:

/MyProject/trunk/version.properties

Dies funktioniert für andere Sprachen als C # und ermöglicht es Ihnen, Ihre Versionsinformationen in Subversion zu speichern.

.NET erledigt das für Sie. Setzen Sie in Ihrer AssemblyInfo.cs-Datei Ihre Assembly-Version auf major.minor. * (Beispiel: 1.0. *).

Wenn Sie Ihr Projekt erstellen, wird die Version automatisch generiert.

Die Build- und Revisionsnummern werden basierend auf dem Datum unter Verwendung der Unix-Epoche generiert, glaube ich. Der Build basiert auf dem aktuellen Tag und die Revision basiert auf der Anzahl der Sekunden seit Mitternacht.

Ich habe noch nie gesehen, dass die Funktion 1.0. * In VS2005 oder VS2008 funktioniert. Muss etwas getan werden, um VS so einzustellen, dass die Werte erhöht werden?

Wenn AssemblyInfo.cs mit 1.0. * Fest codiert ist, wo werden dann die tatsächlichen Builds / Revisionen gespeichert?

Nach dem Einfügen von 1.0. * In AssemblyInfo können wir die folgende Anweisung nicht verwenden, da ProductVersion jetzt einen ungültigen Wert hat - es verwendet 1.0. * Und nicht den von VS zugewiesenen Wert:

Version version = new Version(Application.ProductVersion);

Seufz - das scheint eines der Dinge zu sein, nach denen jeder fragt, aber irgendwie gibt es nie eine solide Antwort. Vor Jahren sah ich Lösungen zum Generieren einer Revisionsnummer und zum Speichern in AssemblyInfo als Teil eines Post-Build-Prozesses. Ich hoffte, dass diese Art von Tanz für VS2008 nicht erforderlich sein würde. Vielleicht VS2010?

Ich gehe davon aus, dass dies auch mit einer Textvorlage möglich ist, in der Sie die betreffenden Assembly-Attribute im laufenden Betrieb aus der Umgebung erstellen, wie dies unten bei AssemblyVersion.tt der Fall ist.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
var build = Environment.GetEnvironmentVariable("BUILD_NUMBER");
build = build == null ? "0" : int.Parse(build).ToString();
var revision = Environment.GetEnvironmentVariable("SVN_REVISION");
revision = revision == null ? "0" : int.Parse(revision).ToString();    
#>
using System.Reflection;
[assembly: AssemblyVersion("1.0.<#=build#>.<#=revision#>")]
[assembly: AssemblyFileVersion("1.0.<#=build#>.<#=revision#>")]

Als Fortsetzung der Antwort von MikeS wollte ich hinzufügen, dass das SDK für Visualisierung und Modellierung von VS + Visual Studio installiert werden muss, damit dies funktioniert, und dass Sie auch die Projektdatei ändern müssen. Sollte auch erwähnt werden, verwende ich Jenkins als Build-Server, der auf einer Windows 2008 R2-Serverbox mit Versionsmodul ausgeführt wird, wo ich die BUILD_NUMBER erhalte.

Meine Textvorlagendatei version.tt sieht so aus

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
var build = Environment.GetEnvironmentVariable("BUILD_NUMBER");
build = build == null ? "0" : int.Parse(build).ToString();
var revision = Environment.GetEnvironmentVariable("_BuildVersion");
revision = revision == null ? "5.0.0.0" : revision;    
#>
using System.Reflection;
[assembly: AssemblyVersion("<#=revision#>")]
[assembly: AssemblyFileVersion("<#=revision#>")]

Ich habe folgendes in den Eigenschaftsgruppen

<PropertyGroup>
    <TransformOnBuild>true</TransformOnBuild>
    <OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
    <TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>

Nach dem Import von Microsoft.CSharp.targets habe ich dies (abhängig davon, wo Sie VS installieren

<Import Project="C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TextTemplating\v10.0\Microsoft.TextTemplating.targets" />

Auf meinem Build-Server habe ich dann das folgende Skript, um die Textumwandlung vor dem eigentlichen Build auszuführen und die letzte Änderungssatznummer in TFS abzurufen

set _Path="C:\Build_Source\foo"

pushd %_Path% 
"%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" history . /r /noprompt /stopafter:1 /Version:W > bar
FOR /f "tokens=1" %%foo in ('findstr /R "^[0-9][0-9]*" bar') do set _BuildVersion=5.0.%BUILD_NUMBER%.%%foo
del bar
popd

echo %BUILD_NUMBER%
echo %_BuildVersion%
cd C:\Program Files (x86)\Jenkins\jobs\MyJob\workspace\MyProject
MSBuild MyProject.csproj /t:TransformAll 
...
<rest of bld script>

Auf diese Weise kann ich Builds UND Änderungssätze verfolgen. Wenn ich also seit dem letzten Build nichts eingecheckt habe, sollte sich die letzte Ziffer nicht ändern. Möglicherweise habe ich jedoch Änderungen am Build-Prozess vorgenommen, sodass die vorletzte Nummer erforderlich ist . Wenn Sie vor einem Build mehrere Check-Ins durchführen, wird natürlich nur die letzte Änderung in der Version angezeigt. Ich denke, Sie könnten verketten, dass dies erforderlich ist.

Ich bin sicher, Sie können etwas ausgefalleneres tun und TFS direkt aus der tt-Vorlage heraus aufrufen, aber das funktioniert bei mir.

Ich kann dann meine Version zur Laufzeit so bekommen

Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
return fvi.FileVersion;

Für meine Lösung müssen keine externen Tools oder Skriptsprachen hinzugefügt werden. Es funktioniert so gut wie garantiert auf Ihrer Build-Maschine. Ich löse dieses Problem in mehreren Teilen. Zuerst habe ich eine BUILD.BAT-Datei erstellt, die den Jenkins BUILD_NUMBER-Parameter in eine Umgebungsvariable konvertiert. Ich verwende Jenkins Funktion "Windows-Batch-Befehl ausführen", um die Build-Batch-Datei auszuführen, indem ich die folgenden Informationen für den Jenkins-Build eingebe:

     ./build.bat --build_id %BUILD_ID% -build_number %BUILD_NUMBER%

In der Build-Umgebung habe ich eine build.bat-Datei, die wie folgt beginnt:

     rem build.bat
     set BUILD_ID=Unknown
     set BUILD_NUMBER=0
     :parse_command_line
     IF NOT "%1"=="" (
         IF "%1"=="-build_id" (
             SET BUILD_ID=%2
             SHIFT
             )
         IF "%1"=="-build_number" (
             SET BUILD_NUMBER=%2
             SHIFT
         )
         SHIFT
         GOTO :parse_command_line
     )
     REM your build continues with the environmental variables set
     MSBUILD.EXE YourProject.sln

Anschließend habe ich im Projektmappen-Explorer von Visual Studio mit der rechten Maustaste auf das zu erstellende Projekt geklickt und Eigenschaften ausgewählt, Ereignisse erstellen ausgewählt und die folgenden Informationen als Befehlszeile für Ereignisse vor dem Erstellen eingegeben, wodurch automatisch eine CS-Datei erstellt wird Informationen zur Build-Nummer basierend auf den aktuellen Einstellungen der Umgebungsvariablen:

     set VERSION_FILE=$(ProjectDir)\Properties\VersionInfo.cs
     if !%BUILD_NUMBER%==! goto no_buildnumber_set
     goto buildnumber_set
     :no_buildnumber_set
     set BUILD_NUMBER=0
     :buildnumber_set
     if not exist %VERSION_FILE% goto no_version_file
     del /q %VERSION_FILE%
     :no_version_file
     echo using System.Reflection; >> %VERSION_FILE%
     echo using System.Runtime.CompilerServices; >> %VERSION_FILE%
     echo using System.Runtime.InteropServices; >> %VERSION_FILE%
     echo [assembly: AssemblyVersion("0.0.%BUILD_NUMBER%.1")] >> %VERSION_FILE%
     echo [assembly: AssemblyFileVersion("0.0.%BUILD_NUMBER%.1")] >> %VERSION_FILE%

Möglicherweise müssen Sie sich an Ihren Build-Geschmack anpassen. Ich erstelle das Projekt einmal manuell, um eine erste Version.cs-Datei im Eigenschaftenverzeichnis des Hauptprojekts zu generieren. Zuletzt füge ich die Datei Version.cs manuell in die Visual Studio-Lösung ein, indem ich sie in den Bereich des Projektmappen-Explorers unter der Registerkarte Eigenschaften für dieses Projekt ziehe. In zukünftigen Builds liest Visual Studio diese CS-Datei dann zur Jenkins-Build-Zeit und erhält die richtigen Informationen zur Build-Nummer.

Wir haben also ein Projekt mit einer Lösung, das mehrere Projekte enthält, die Assemblys mit unterschiedlichen Versionsnummern haben.

Nachdem ich einige der oben genannten Methoden untersucht hatte, implementierte ich gerade einen Erstellungsschritt, um ein Powershell-Skript auszuführen, das ein Suchen und Ersetzen für die AssemblyInfo.cs-Datei ausführt. Ich verwende immer noch die Versionsnummer 1.0. * In der Quellcodeverwaltung, und Jenkins aktualisiert die Versionsnummer nur manuell, bevor msbuild ausgeführt wird.

dir **/Properties/AssemblyInfo.cs | %{ (cat $_) | %{$_ -replace '^(\s*)\[assembly: AssemblyVersion\("(.*)\.\*"\)', "`$1[assembly: AssemblyVersion(`"`$2.$build`")"} | Out-File $_ -Encoding "UTF8" }
dir **/Properties/AssemblyInfo.cs | %{ (cat $_) | %{$_ -replace '^(\s*)\[assembly: AssemblyFileVersion\("(.*)\.\*"\)', "`$1[assembly: AssemblyFileVersion(`"`$2.$build`")"} | Out-File $_ -Encoding "UTF8" }

Ich habe die Option -Encoding "UTF8" hinzugefügt, weil Git damit begonnen hat, die CS-Datei als Binärdateien zu behandeln, wenn ich dies nicht getan habe. Zugegeben, das war egal, da ich das Ergebnis nie wirklich festschreibe; es kam gerade auf, als ich testete.

Unsere CI-Umgebung verfügt bereits über eine Funktion, um den Jenkins-Build mit dem jeweiligen Git-Commit zu verknüpfen (danke Stash-Plugin!). Ich mache mir also keine Sorgen, dass es kein Git-Commit mit der angehängten Versionsnummer gibt.

Dies ist ein einfacherer Mechanismus. Es umfasst lediglich das Hinzufügen eines Windows Batch-Befehls-Task-Erstellungsschritts vor dem MSBuild-Schritt und die Verwendung eines einfachen Such- und Ersetzungsprogramms (FART).

Der Batch-Schritt

fart --svn -r AssemblyInfo.cs "[assembly: AssemblyVersion(\"1.0.0.0\")]" "[assembly: AssemblyVersion(\"1.0.%BUILD_NUMBER%.%SVN_REVISION%\")]"
if %ERRORLEVEL%==0 exit /b 1
fart --svn -r AssemblyInfo.cs "[assembly: AssemblyFileVersion(\"1.0.0.0\")]" "[assembly: AssemblyFileVersion(\"1.0.%BUILD_NUMBER%.%SVN_REVISION%\")]"
if %ERRORLEVEL%==0 exit /b 1
exit /b 0

Wenn Sie eine andere Quellcodeverwaltung als svn verwenden, ändern Sie die Option --svn für die entsprechende Option für Ihre scm-Umgebung.

Furz herunterladen

Ich habe mich entschlossen, einige Methoden mit einem vorgefertigten Powershell-Skript ( https://gist.github.com/bradjolicoeur/e77c508089aea6614af3 ) zu verwenden, um jeden erfolgreichen Build in Global.asax zu erhöhen. Ich gehe ungefähr so ​​vor:

  // We are using debug configuration, so increment our builds.
  if (System.Diagnostics.Debugger.IsAttached)
  {
      string version = System.Reflection.Assembly.GetExecutingAssembly()
                                                       .GetName()
                                                       .Version
                                                       .ToString();

      var psi = new ProcessStartInfo(@"svn", "commit -m \"Version: " + version + "\n \"");
      psi.WorkingDirectory = @"C:\CI\Projects\myproject";
      Process.Start(psi); 
  }

Ich denke immer noch, dass der gesamte Prozess überkompliziert ist und ich werde nach einer effizienteren Methode suchen, um das gleiche Ergebnis zu erzielen. Ich wollte dies hauptsächlich, um die Version an SVN und dann an Jenkins ohne zu viele zusätzliche Tools zu übergeben.