Teil 1: Funktionalität automatisiert für andere Anwendungen bereitstellen

Päckchen packen mit NuGet und TFS
Kommentare

Der Open-Source-Paketmanager NuGet hat sich in der .NET-Welt zur Standardmethode entwickelt, um Funktionalität zwischen mehreren Projekten zu teilen oder öffentlich bereitzustellen – fast jeder Programmierer hat schon ein NuGet-Paket in sein Projekt eingebunden. Doch NuGet kann mehr: Es bietet die Möglichkeit, wichtige Teile des Entwicklungsprozesses innerhalb der eigenen Organisation weiter zu verbessern und zu automatisieren.

Der Paketmanager NuGet ermöglicht es, Funktionalität in handliche, versionierte Pakete (NuGet-Packages) zu packen und diese dann einfach für mögliche Konsumenten bereitzustellen. Das Tool war zunächst als Visual-Studio-Erweiterung und Konsolenprogramm verfügbar, ab Visual Studio 2012 ist NuGet in die Entwicklungsumgebung integriert.

Über öffentlich verfügbare Paketserver wie nuget.org ist es sehr einfach, solche Packages zu veröffentlichen. Mittlerweile gibt es praktisch keine populäre Bibliothek mehr, die nicht über NuGet in das eigene Projekt eigebunden werden kann – auch Microsoft selbst nutzt NuGet extensiv für die Bereitstellung von wichtigen Komponenten. Viele Visual-Studio-Projektvorlagen enthalten Referenzen auf NuGet-Packages, und selbst Teile des .NET Frameworks selbst werden mittlerweile auf diesem Weg ausgeliefert. Im März 2015 standen allein auf nuget.org über 34 000 Pakete zum Download bereit.

In diesem Artikel wollen wir zwar zunächst einen Blick darauf werfen, wie man Pakete „konsumiert“ , aber bekanntlich ist Selbermachen viel schöner und nachhaltiger als Konsum. Deshalb zeigen wir auch, wie man „Päckchen packt“ – und zwar voll automatisiert und integriert in den Build-Prozess.

Im zweiten Teil des Artikels geht es dann darum, wie NuGet den Softwareprozess in der eigenen Organisation verbessern kann.

Also, packen wir’s ein an!

Artikelserie

Pakete verwenden

Verfügbare NuGet-Pakete zu nutzen ist sehr einfach: Packages werden in Visual Studio über den Befehl Manage NuGet Packages in die Projekte eingebunden. Dieser Befehl steht im Solution Explorer im Kontextmenü auf dem Eintrag der Solution, auf den Einträgen der einzelnen Projekte sowie in den Projekten auf dem Ordner References zur Verfügung, wobei sich der Aufruf auf dem Projekt oder über References nicht unterscheidet.

Sollen Pakete in mehrere Projekte eingebunden werden, empfiehlt sich der Aufruf von Manage NuGet Packages auf dem Solution-Eintrag: Es öffnet sich ein Dialog, in dem man auswählen kann, auf welche Projekte innerhalb der Solution die betreffende Referenz gesetzt werden soll (Abb. 1).

Abb. 1: Einfügen eines neuen NuGet-Pakets auf Solution-Ebene

Abb. 1: Einfügen eines neuen NuGet-Pakets auf Solution-Ebene

In einem weiteren Dialog, dem Package Manager, lassen sich dann die einzelnen Packages suchen und installieren. Gerade die Suchfunktion ist dabei sehr hilfreich, denn wie erwähnt gibt es mittlerweile eine fast unüberschaubare Anzahl von verfügbaren Paketen.

Das Paketmanagement untergliedert sich in drei unterschiedliche Bereiche:

Installed Packages: Hier werden alle Pakete angezeigt, die bereits im aktuellen Projekt bzw. in der Solution installiert sind. In dieser Rubrik lassen sich die Packages übrigens auch deinstallieren.

Online: Hier werden alle Packages angezeigt, die zur Installation zur Verfügung stehen. Diese Rubrik ist in verschiedene Paketserver unterteilt. Wir werden etwas später sehen, wie man diese Package Sources konfigurieren kann.

Updates: Hier werden Packages angezeigt, die bereits installiert sind und für die Updates bereitstehen.

Sie müssen also darauf achten, dass Sie im richtigen Bereich sind, da sonst eventuell das gewünschte Package gar nicht angezeigt wird, beziehungsweise die gewünschte Aktion nicht zur Verfügung steht (Abb. 2).

Abb. 2: Der NuGet-Package-Manager

Abb. 2: Der NuGet-Package-Manager

Über den Button Settings lässt sich der Package Manager konfigurieren. Dies bezieht sich vor allem auf die für die Paketsuche verfügbaren Server – so können auch weitere alternative Quellen wie beispielsweise myget.org oder eigene lokale Quellen eingebunden werden (Abb. 3).

Abb. 3: Konfiguration des Package-Managers

Abb. 3: Konfiguration des Package-Managers

NuGet-Paketreferenzen

Was passiert nun beim Einbinden einer NuGet-Paketreferenz? Beim Installieren eines Pakets legt NuGet automatisch innerhalb des entsprechenden Projekts eine Datei mit dem Namen packages.config an. In dieser Konfigurationsdatei merkt sich NuGet, welche Pakete in welcher Version im entsprechenden Projekt installiert sind (Listing 1).


Die Pakete werden dann vom entsprechenden Server heruntergeladen und in einem Ordner namens packages abgelegt, der auf der Ebene des Solution-Files angelegt wird. Somit sind die Pakete auch nutzbar, wenn keine Verbindung zum Server besteht. Nun wird eine Referenz auf die entsprechende Datei unterhalb des Packages-Ordners im Projekt eingetragen. Pakete können zusätzlich auch noch weitere Dateien, zum Beispiel Hilfe- oder Beispieldateien in das Projekt einbinden. So kann die Verwendung eines Pakets für den Nutzer vereinfacht werden. Zudem besteht die Möglichkeit, Konfigurationsdateien zu manipulieren und dort zusätzliche Einträge einzufügen, die bei der Deinstallation des Pakets auch wieder entfernt werden. Ein weiterer Vorteil besteht darin, dass Abhängigkeiten zu anderen Paketen definiert werden können und beim Installieren eines Packages diese Abhängigkeiten erkannt und die entsprechenden Pakete automatisch mitinstalliert werden.

Software Architecture Summit 2017

The Core of Domain-Driven Design

mit Carola Lilienthal (Workplace Solutions)

Distributed Systems

mit Kyle Kingsbury (Independent Consultant)

Versionierung von Paketen

Einer der großen Vorteile beim Einsatz von NuGet ist, dass der Package Manager einen Versionierungs- und Updatemechanismus mitbringt. Jedes Paket hat eine eindeutige Versionsnummer. Die Referenz im Projekt wird von NuGet immer auf die in der packages.config angegebene Version gesetzt, sodass durch die Bereitstellung einer neuen Version eines Pakets sich das Verhalten zunächst nicht verändert, da das Projekt immer noch die alte Version nutzt. Im Package Manager werden alle Pakete angezeigt, für die es eine neuere Version gibt. Diese können von dort entsprechend aktualisiert werden. Die neue Version des Pakets wird dann in den packages-Ordner heruntergeladen und die Referenz auf die neue Version abgeändert.

Spezifische Version von Paketen installieren

Über oben gezeigten Package-Manager-Dialog lässt sich nur die jeweils aktuellste Version eines Packages installieren. Soll eine ältere Version installiert werden, steht dazu in Visual Studio über das Menü Tools | NuGet Package eine spezielle PowerShell-Kommandozeile namens Package Manager Console bereit. Diese ermöglicht mittels diverser Commandlets fortgeschrittene NuGet-Operationen wie die Installation von spezifischen Paketversionen. Eine Dokumentation dazu findet sich auf der offiziellen NuGet-Website. Mit der neuesten NuGet-Version, die mit Visual Studio 2015 kommen wird, können dann auch im NuGet Package Manager spezifische Versionen ausgewählt werden (Abb. 4).

Abb. 4: NuGet-Funktionen in Visual Studio

Abb. 4: NuGet-Funktionen in Visual Studio

 

NuGet und Versionsverwaltung

Bei der Verwaltung von Solutions mit NuGet-Referenzen über die Versionsverwaltung zeigt NuGet ein erwartetes aber trotzdem etwas unglückliches Verhalten: Standardmäßig wird der packages-Ordner in der Versionsverwaltung mit eingecheckt. Dies hat zwar den Vorteil, dass die entsprechenden Pakete auch nach Auschecken der Solution durch einen anderen Benutzer sofort verfügbar sind – andererseits können die Pakete jederzeit vom jeweiligen Paketserver geladen werden, was das Einchecken in die Versionsverwaltung unnötig macht. Leider gibt es dazu keinen einfachen Befehl in den Visual-Studio-Einstellungen. Stattdessen ist hierfür ein Eintrag (disableSourceControlIntegration) in der NuGet-Konfigurationsdatei nötig. Diese Datei mit dem Namen NuGet.config findet sich im Verzeichnis .nuget auf der Ebene der Solution – falls die Datei nicht existiert, kann sie auch manuell erstellt werden (Listing 2). Achtung: Beim Anlegen des Ordners .nuget nicht verzweifeln: Der Windows Explorer kann keine Verzeichnisse anlegen, die mit einem Punkt beginnen. Hier hilft der gute alte DOS-Befehl mkdir weiter. Wichtig auch: Änderungen an der Konfigurationsdatei werden erst nach Neustart von Visual Studio wirksam.


Nachdem das Einchecken des packagesOrdners unterbunden wurde, müssen die fehlenden Pakete dem Projekt vor einem Build wieder hinzugefügt werden, wenn die Solution an anderem Ort wieder frisch ausgecheckt wird. Dies erledigt NuGet automatisch per Package Restore. NuGet lädt dabei vor der eigentlichen Kompilierung die benötigten Pakete automatisch herunter, sobald in Visual Studio ein Build gestartet wird. Auch Team Builds auf einem dedizierten Build-Server werden unterstützt. Standardmäßig ist die Package-Restore-Funktion in Visual Studio aktiviert, kann jedoch in den NuGet-Einstellungen auch abgeschaltet werden.

Ab der NuGet-Version 2.7 ist Package Restore in Visual Studio integriert (Abb. 5).

Abb. 5: Aktivierung des integrierten Package Restore in Visual Studio

Abb. 5: Aktivierung des integrierten Package Restore in Visual Studio

Davor wurde ein MSBuild-basierter Mechanismus verwendet. Für diese Variante steht nach wie vor die Option Enable NuGet Package Restore im Kontextmenü der Solution alternativ zur integrierten Restore-Funktionalität zur Verfügung (Abb. 6). Über die Vor- und Nachteile beider Verfahren gibt die NuGet-Website ausführlich Auskunft.

Abb. 6: Aktivierung des MSBuild-basierten Package Restore im Kontextmenü der Solution

Abb. 6: Aktivierung des MSBuild-basierten Package Restore im Kontextmenü der Solution

Pakete selbst erstellen

Zur Erstellung von NuGet-Paketen gibt es verschiedene Vorgehensweisen, die im Rahmen verschiedener Anwendungsfälle jeweils kleinere Vor- und Nachteile haben. Wir stellen im Folgenden eine Vorgehensweise vor, die sich für Softwareteams bewährt hat, die Komponenten im Rahmen von Visual Studio Team Build bauen. Die vorgestellte Lösung synchronisiert zudem die Version eines Packages mit der Version der enthaltenen Komponente – ein oft erwünschtes und sehr praxistaugliches Verhalten.

In unserem Szenario soll eine Komponente eines Projekts – eine Mathematikbibliothek namens MathLib – als NuGet-Paket bereitgestellt werden.

NuGet bietet für die Erstellung und Konfiguration von Paketen den Kommandozeilenbefehl nuget.exe. Um ein Paket aus einem Visual-Studio-Projekt zu erzeugen, reicht der simple Befehl:

nuget pack MathLib.csproj

Diese Methode erzeugt allerdings nur ein sehr einfaches Package, das schlicht den Build-Output des Projekts enthält – es kann nichts weiter konfiguriert werden. Die Definition des gewünschten Paketinhalts kann über ein Konfigurationsfile mit dem Namen .nuspec erfolgen, und erfreulicherweise kann der nuget-Befehl auch gleich das Konfigurationsfile erzeugen, wenn der Parameter spec übergeben wird:

nuget spec MathLib.csproj

Als Resultat wird ein einfaches .nuspec-File mit Standardinhalt generiert (Listing 3).

 #?xml version="1.0"?>

  
    $id$
    $version$$title$
    $author$
    $author$
    	http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE
    http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE
    http://ICON_URL_HERE_OR_DELETE_THIS_LINE
    false
    $description$
    Summary of changes made in this release of the package.
    Copyright 2013
    Tag1 Tag2
  

Was hier auffällt sind die eingebetteten Variablen, wie zum Beispiel $id$ und $version$. Dabei handelt es sich um Replacement Tokens. Beim Erstellen eines Packages mit dem oben beschriebenen Befehl wird die .nuspec-Datei herangezogen, und die Variablen darin werden durch Informationen aus dem Projekt ersetzt. Das klappt jedoch nicht für alle Replacement Tokens. Manche Werte, wie beispielsweise Autor und Beschreibung müssen entweder in der .nuspecDatei fest eingetragen oder an den nuget pack-Befehl als Argument übergeben werden:

nuget pack MathLib.csproj -p author=Thomas;description=“Math Lib“

Mittels des .nuspec-Files kann der Inhalt des Pakets problemlos genau gesteuert werden, um beispielsweite weitere Dateien, Abhängigkeiten etc. mit einzubinden. Da die .nuspec-Datei eine Projektkonfigurationsdatei ist, sollte sie in das Projekt mit aufgenommen werden.

Pakete automatisch aktualisieren

Über den nuget-Befehl lässt sich jetzt bequem ein Paket erzeugen. Ideal wäre es jedoch, wenn bei jedem Build automatisch eine aktualisierte Version des Pakets erzeugt würde. Glücklicherweise ist dieses Vorhaben nicht schwer zu realisieren – vorausgesetzt man kennt sich mit MSBuild aus. Wenn nicht, empfiehlt sich die Lektüre der entsprechenden MSDN-Dokumentation. Denn für die folgenden Schritte kommt die oben bereits angesprochene MSBuild-basierte Integration von NuGet zum Einsatz.

Um die dafür benötigten Dateien der Solution hinzuzufügen, reicht es, den Kontextbefehl Enable NuGet Package Restore auf der aktuellen Solution aufzurufen (Abb. 7).

Abb. 7: Dateien für den MSBuild-basierten Package Restore hinzufügen

Abb. 7: Dateien für den MSBuild-basierten Package Restore hinzufügen

Als Resultat wird ein Ordner angelegt, in dem sich drei Dateien befinden: Die Befehlsdatei nuget.exe, die bereits erwähnte Konfigurationsdatei nuget.config und eine dritte Datei namens nuget.targets (Abb. 7). Dabei handelt es sich um ein Erweiterungsskript für MSBuild, das die Funktionalität zum automatischen Erstellen von Packages nach dem Build-Vorgang hinzufügt.

Die Einbindung der targets-Datei geschieht in der aktuellen Projektdatei – denn Projektdateien sind ebenfalls MSBuild-Skripte, die während des Build-Vorgangs ausgeführt werden. Um die Projektdatei zu editieren, muss diese zunächst aus Visual Studio entladen werden – hierzu gibt es den Befehl Unload Project im Kontextmenü des Projekts (Abb. 8).

Abb. 8: Projekt entladen

Abb. 8: Projekt entladen

Die Projektdatei kann dann problemlos bearbeitet werden (Abb. 9). Die nötigen Änderungen sind simpel und beschränken sich auf zwei Tags (fett markiert in Listing 3).

Abb. 9: Projektdatei bearbeiten

Abb. 8: Projekt entladen

 
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  
  
    Debug
    true
  
[...]
  
  

Nach dem erneuten Laden der Projektdatei kann das Projekt wieder gebaut werden. Im Output-Verzeichnis ist jetzt das NuGet-Paket zu finden. Zusätzlich wird noch ein symbols-Paket erzeugt, das die Debugging-Symbole enthält (Abb. 10).

Abb. 10: Inhalt des erstellten NuGet-Packages

Abb. 10: Inhalt des erstellten NuGet-Packages

Bauen im Team

Für lokale Builds funktioniert die vorgestellte Lösung sehr gut, sie stößt jedoch an ihre Grenzen, wenn das Paket in einem zentralen Team Build auf einem Build-Server gebaut werden soll.

Damit der Build alle notwendigen Dateien nutzen kann, müssen die .nuspecDatei, der .nuget-Ordner mit der nuget.exe und der nuget.targets-Datei sowie der nuget.config-Datei in die Versionsverwaltung eincheckt werden. Doch das reicht nicht – bei einem Team Build tritt trotzdem der folgende Fehler auf: C:Builds1PresentationsMathLib Mainsrc.nugetNuGet.targets (103): Unable to find ‚C:Builds1PresentationsMathLib MainsrcMathLibbinDebugMathLib.dll‘. Make sure the project has been built.

Dieses Problem rührt daher, dass der Team Build einen anderen Output-Pfad verwendet als der lokale Build. NuGet bindet aber bei der Übergabe der .csprojDatei immer den Output des Projekts in das Paket ein. Dieser wiederum wird in dem Pfad gesucht, der in der .csproj-Datei definiert ist. Da es leider zum Zeitpunkt der Erstellung dieses Artikels keine Möglichkeit gibt, dieses Verhalten zu überschreiben, funktioniert dieser Weg nicht für den Team Build. Eine andere Lösung muss her. Zeit, noch tiefer in die MSBuild-Trickkiste zu greifen.

Der NuGet-Befehl erlaubt auch die Übergabe der oben bereits beschriebenen .nuspec-Datei:

nuget pack MathLib.nuspec

Der Haken dabei: Bei dieser Methode werden die Replacement Tokens nicht mehr aus der AssemblyInfo.cs übernommen (Abb. 11).

Abb. 11: Fehlende Informationen beim Aufruf von „nuget pack“

Abb. 11: Fehlende Informationen beim Aufruf von „nuget pack“

Dies bedeutet, dass die Parameter entweder direkt in der .nuspec-Datei definiert oder per Parameter übergeben werden müssen. Weiterhin muss im targets-Skript anstelle der .csproject-Datei die nuspec-Datei aufgerufen werden. Dies geschieht am besten über eine selbst definierte Build Action. Dazu sind einige Änderungen in der targets-Datei nötig.

Unterhalb der ersten Property Group wird eine neue ItemGroup hinzugefügt (Listing 4).


Damit wird eine neue Build Action definiert, die dann auf die .nuspec-Datei in Visual Studio anwendbar ist. So kann die Erstellung des Pakets einfach aus der Entwicklungsumgebung gesteuert werden. Ein neues MSBuild-Target BuildPackageForNuspec unterhalb des letzten target-Blocks erstellt über den Nuget-Befehl jetzt das Package und übernimmt dabei als Parameter die Ausgabedateien des Build-Prozesses sowie die Konfiguration (Listing 5).

 '$(PackageOutputDir)%(FileName)*.nupkg'">
  

Schließlich wird durch Anpassung des BuildDependsOn-Tags dieses neue Build-Target aufgerufen (Listing 6).

  $(BuildDependsOn);
  BuildPackageForNuspec;

Nach Speichern der Änderungen und einem Neustart von Visual Studio lässt sich die neu definierte Build Action für die .nuspec-Datei einstellen (Abb. 12).

Abb. 12: NuGet Build Action für die „.nuspec“-Datei

Abb. 12: NuGet Build Action für die „.nuspec“-Datei

Nun funktioniert das Erstellen des Pakets im Build problemlos. Aber noch ist das Ziel leider nicht ganz erreicht: Ein Blick in das Paket mittels des praktischen Tool Package Explorers zeigt nämlich, dass zwar die Metadaten korrekt sind, aber statt den gebauten Binärdateien gleich das ganze Projektverzeichnis in das Paket verpackt wurde (Abb. 13).

Abb. 13: Zuviel des Guten: Alle Projektdateien wurden in das Paket verpackt

Abb. 13: Zuviel des Guten: Alle Projektdateien wurden in das Paket verpackt

Um dieses Problem zu beheben, müssen in der .nuspec-Datei die zu verpackenden Dateien explizit angegeben werden. Dazu wird ein Replacement Token verwendet, das angibt, wo die Datei nach dem Build liegt. Listing 7 zeigt die resultierende .nuspecDatei.

 

  
    MathLib
    1.1.0Math Lib
    artiso
    artiso
    	http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE
    http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE
    http://ICON_URL_HERE_OR_DELETE_THIS_LINE
    false
    My Math Lib
    Summary of changes made in this release of the package.
    Copyright 2013
    Tag1 Tag2
  
  
    
  

Auch die .targets-Datei muss angepasst werden, damit der entsprechende Parameter korrekt übergeben wird (Listing 8).

 Target Name="BuildPackageForNuspec" DependsOnTargets="CheckPrerequisites" Inputs="@(Nuget);" Outputs="@(Nuget ->'$(PackageOutputDir)%(FileName)*.nupkg'">
  

Jetzt funktioniert endlich alles wie gewünscht: Auch nach einem Check-in erzeugt der TFS Team Build das Package und kopiert es in das Drop-Verzeichnis. Von dort kann das Package nun manuell oder im Build-Prozess in ein NuGet Repository hochgeladen werden, und andere Nutzer können es in eigene Projekte einbinden.

Pakete versionieren

Eine letzte Anpassung erhöht den Komfort bei der Paketerstellung noch weiter und sorgt dafür, dass auch beim automatisierten Team Build des Pakets dessen Versionsinformation mit der Version der enthaltenen Assembly synchron gehalten wird.

Um dies zu bewerkstelligen, ist etwas .NET-Code nötig. Dieser kann mittels einer Inline-Task direkt „inline“ im Build-Skipt ausgeführt werden – ein leistungsfähiges Feature, das ab MSBuild 4.0 verfügbar ist.

Zunächst müssen die zu übergebenden Parameter für die Versionierung im Skript definiert werden. Das geschieht über eine PropertyGroup-Definition vor dem ersten TargetTag (Listing 9).


Am Ende der .nuspec-Datei (vor dem letzten project-Tag) wird die Task ReadVersionFromAssembly definiert, die – nomen est omen – die Versionsnummer der Assembly ausliest und in die eben definierten Parameter schreibt (Listing 10).


Das Targetskript BuildPackeForNuspec kann nun diese Task einfach aufrufen (Listing 11).

 '$(PackageOutputDir)%(FileName)*.nupkg'">
  
    
    
    
    
  
                           
  


  
  
  
  

Zu guter Letzt sorgt ein Replacement Token in der .nuspec-Datei dafür, dass die Version korrekt an den nuget pack-Befehl übergeben wird (Listing 12).

<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  
    MathLib
    $Version$Math Lib
    artiso
    artiso
    	<a href="http://www.artiso.com" class="elf-external elf-icon" rel="nofollow">http://www.artiso.com
    <a href="http://www.artiso.com" class="elf-external elf-icon" rel="nofollow">http://www.artiso.com
    <a href="http://www.artiso.com" class="elf-external elf-icon" rel="nofollow">http://www.artiso.com
    false
    My Math Lib with pdb
    This is a test version to evaluate how to create NuGet packages
    Copyright 2013
    Math
  
  
    
  

Die fertige Lösung bietet jetzt einen sehr hohen Komfort bei der Erstellung von NuGet-Paketen: Bei einem Build wird erst die Assembly erstellt und anschließend deren Version als Parameter übergeben. Das NuGet-Package hat damit nun die gleiche Version wie die enthaltene Assembly und das sowohl im lokalen wie im TFS Team Build. In beiden Fällen können natürlich die klassischen Versionierungsmechanismen für die Assembly verwendet werden. Beispielsweise kann durch einen Sternplatzhalter (*) in der AssemblyInfo-Datei die Build-Nummer automatisch erhöht oder beim Build explizit eine bestimmte Versionsnummer zugewiesen werden.

In der Praxis hat sich folgende Vorgehensweise als praktisch erwiesen: In der AssemblyInfo-Datei wird die Versionsnummer fest auf 99.99.99.99 gesetzt. Der TFS Build setzt dann die Version auf eine eindeutige Versionsnummer. Damit ist einfach zu erkennen, ob es sich bei einer Assembly um eine lokal gebaute handelt oder ob diese vom TFS Build erzeugt wurde und damit einige zusätzliche Qualitätsprüfungen durchlaufen hat.

To be continued …

Wir sind weit gekommen und können jetzt Funktionalität automatisiert in NuGet-Pakete verpacken. Im zweiten Teil des Artikels in der nächsten Ausgabe geht es folgerichtig an das Ausliefern der Pakete: Wie können NuGet-Packages öffentlich oder intern in der Organisation verteilt werden? Und wie verhält es sich dabei mit dem Debugging? Und wieviel Porto kostet eigentlich so ein NuGet-Paket?

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Aufmacherbild: a mound of gold on a old wooden work table via Shutterstock.com / Urheberrecht: optimarc

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -