Paket Dependency Manager für .NET

Paket ist ein Dependency Manager für .NET, welcher es sich zum Ziel gesetzt hat einige Probleme von NuGet zu beheben. Dazu gehören unter anderem folgende Punkte:

  1. Wenn es einen Versionskonflikt zwischen Abhängigkeiten zweier Packages gibt, so referenziert NuGet silent die neuste Version dieses Packages
  2. NuGet kennt keinen Dependency-Graph und es kann nicht zwischen direkten und transitiven Abhängigkeiten unterscheiden werden
  3. NuGet kann Dependencies nicht locken, was Performance und Reproducibility verschlechtert (wichtig für CI Builds)
  4. NuGet hat ohne Mono keinen Linux Support
  5. NuGet hat mit Mono in der Linux Bash keine Shell Completion

Features

Paket ist vom Aufbau her ganz anders als NuGet. Es gibt dabei im Root Folder der Solution nur ein File, in welchem man alle Dependencies auflistet.

“paket.dependencies” File

Source gibt dabei die Quelle des NuGet Repositories an.

Paket unterstützt derzeit folgende Dependency-Typen: git, nuget, github, gist und http.

Bei Gist, Github und Git kann man natürlich auch den Commit Hash angeben, um immer die gleiche Version zu erhalten. Nicht möglich ist Versionierung bei HTTP Dependencies.

Durch die Direktive «clitool» erkennt Package auch, dass «xunit» in diesem Beispiel ein Executable ist, mit welchem man die Tests ausführt. Dies funktioniert aber nicht nur für CLI Tools; enthält bspw. ein NuGet Package einen Roslyn Analyzer, so wird dieser automatisch zum Build Prozess hinzugefügt.

Wenn man Paket in einer Firma verwendet, ist es oft praktisch einen gemeinsamen Package Cache zu verwenden. Paket unterstützt auch dies. Im «paket.dependencies» File kann man auch folgendermaßen einen Package-Cache angeben, welcher dann für alle Packages verwendet werden soll: «cache //hive/dependencies»

Neben dem «paket.dependencies» File gibt es pro Projekt in der VS-Solution ein «paket.references» File. Dieses beinhaltet alle Packages vom «paket.dependencies» File (nur Name), welche zum Builden dieses Projektes benötigt werden. Für das obige Beispiel in einem Assembly mit AutoMapper sähe dies dann so aus:

“paket.references” File

Wenn man auf der Commandline «paket install» ausführt, um alle Packages zu installieren, wird auch noch automatisch ein «paket.lock» (ähnlich npm) File im Root der Solution erstellt. Diese Files sollten in das Repository eingecheckt werden und enthalten alle exakten transitiven und direkten Dependencies. Dies hat zum Vorteil, dass beim nächsten Mal wieder exakt der gleiche Stand wiederhergestellt werden kann. Außerdem führt dies auch zu Performance Improvements bei der CI, da das Resolven von transitiven Abhängigkeiten wegfällt. Hier wäre z.B. ein Auszug aus einem «paket.lock» File:

“paket.lock” File

Einrichten von Paket

Nebst den vielen Features ist Paket nicht nur sehr einfach aufzusetzen, sondern auch noch sehr einfach von NuGet zu Paket zu migrieren. Um Paket zu verwenden, muss im Root der Solution nur ein «paket.bootstrapper.exe» (umbenannt zu «paket.exe», siehe https://fsprojects.github.io/Paket/bootstrapper.html) in einem Folder «.paket» abgelegt werden.

  • mkdir .paket
  • wget -O paket.exe https://github.com/fsprojects/Paket/releases/download/5.190.0/paket.bootstrapper.exe

​5.190.0 muss dabei einfach durch die aktuell neuste Version ersetzt werden.

Nachdem man Paket das erste Mal ausgeführt hat, werden einige Paket Files erstellt. Diese (und auch die umbenannte «paket.exe») sollte man gleich ins Repository einchecken.

Um nun die Dependencies anzugeben, kann man diese einfach im «paket.dependencies» File anpassen und danach «.paket/paket.exe install» ausführen.

Migration von NuGet

Wenn man eine bestehende Solution von NuGet zu Paket migrieren möchte, so kann man nur «paket convert-from-nuget» ausführen. Der Vorteil dabei ist auch, dass die Package References gleich aus allen .csproj-Dateien entfernt werden und man danach eine saubere Solution hat. Außerdem registriert sich Paket im .csproj-File als Tool. Dies ermöglicht es, dass bei «dotnet restore» (.NET Core) automatisch «paket install» anstatt «nuget restore» aufgerufen wird. Bei der Migration eines internen Projektes von NuGet auf Paket muss somit nichts an der CI angepasst werden und es funktionierte trotzdem weiterhin noch alles wie gewohnt, da alle benötigten Files (inkl. Bootstrapper Executable) direkt in der Solution sind und die CI «dotnet restore» aufruft.

Fazit

Paket ist somit eine sehr Feature-reiche Alternative zu NuGet, welche viele Probleme von NuGet behebt, aber trotzdem immer noch Kompatibilität mit der NuGet Registry bewahrt.

Um mehr über Paket zu erfahren, ist es empfehlenswert die offiziellen Github-Pages des Projektes durchzulesen: https://fsprojects.github.io/Paket/.

 

Bildnachweise

  • Paket Dependency ManagerTitel: Paket
By |2018-12-07T13:38:35+01:00December 7th, 2018|ASP.net|0 Comments

About the Author:

Associate Technology Specialist

Leave a Reply

%d bloggers like this:

novaCapta verwendet Cookies, um die Funktionalität dieser Website zu verbessern. Durch die Nutzung dieser Seite stimmen Sie der Verwendung von Cookies zu. Weiterlesen

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close