.NET – Paket Dependency Manager

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

Erfahren Sie mehr

Office 365 Groups als Evolution von SharePoint?
Blog
Blog

Office 365 Groups als Evolution von SharePoint?

Zusätzlich zu SharePoint erlauben die Office 365 Groups es mir als Anwender, schnell und einfach neue Gruppen anzulegen und selbständig Benutzer hinzuzufügen.

Das neuste Mitglied der Office 365 Familie: Delve
Blog
Blog

Das neuste Mitglied der Office 365 Familie: Delve

Microsoft legt nach: Mit Delve startet eine neue Form des Suchens und des Auffinden von Dokumenten und Informationen.

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow
Blog
Blog

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow

Die Power Platform wird aktuell von Microsoft sehr stark gepusht. Zeit, sich mit dem Potenzial der einzelnen Komponenten zu beschäftigen. Heute: Flow.

Azure Functions: Der Webservice ohne Webserver
Blog
Blog

Azure Functions: Der Webservice ohne Webserver

Azure Functions als Authentifizierungs-Helfer für clientseitige Lösungen mit 3rd Party APIs

Sprechen Sie LUIS? – Der intelligente Chat-Bot im Praxistest
Blog
Blog

Sprechen Sie LUIS? – Der intelligente Chat-Bot im Praxistest

Mit LUIS, der Sprach- und Texterkennungssoftware von Microsoft, und dem Bot Framework von Azure haben wir eine Lösung für den IT-Support entwickelt.

Nov
07
Webcast mit Microsoft: Das Intranet zu Ende gedacht
Webinar
Webinar

Webcast mit Microsoft: Das Intranet zu Ende gedacht

Am 07. November findet erneut eines unserer Webinare gemeinsam mit Mircosoft statt. Das Thema dieses Mal: Das Intranet zu Ende gedacht – Die Informationszentral...

novaCapta auf der Fachtagung für Interne Revision
Event
Event

novaCapta auf der Fachtagung für Interne Revision

Das Expertenteam der novaCapta präsentiert am 15. und 16. November ihre innovative Audit Management Lösung auf dem DIIR-Kongress in Dresden. Besuchen Sie unsere...

PowerApps – Neuigkeiten, Übersicht, Tipps & Tricks
Blog
Blog

PowerApps – Neuigkeiten, Übersicht, Tipps & Tricks

Neues aus der Welt von PowerApps

Valo ist neuer Partner der novaCapta für Intranets
News
News

Valo ist neuer Partner der novaCapta für Intranets

Durch die Partnerschaft mit Valo, dem Ready-2-Go Intranet-Baukasten aus Finnland baut die novaCapta ihr Angebot bei der Umsetzung von schnellen und funktionalen...

Mit der HoloLens ein Stück Berlin nach Köln holen
News
News

Mit der HoloLens ein Stück Berlin nach Köln holen

Im Rahmen eines zweitägigen Hackathons haben sich einige Mitarbeiter der novaCapta der Microsoft HoloLens und dem Thema Mixed Reality gewidmet. Dabei haben wir...

May
04
novaCapta auf der dotnet Cologne
Event
Event

novaCapta auf der dotnet Cologne

In nächster Nachbarschaft zu unserem Kölner Büro findet am 04. und 05. Mai die dotnet Cologne im KOMED statt. Wir von der novaCapta sind auch dabei.

Auf Goldkurs in der Cloud
News
News

Auf Goldkurs in der Cloud

Die novaCapta hat ihren Partnerstatus bei Microsoft zusätzlich vergoldet: Auch in der Sparte Cloud Productivity haben wir jetzt den Goldstatus.