.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

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

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

Jan
25
Webcast mit Microsoft: Fit für die digitale Arbeitswelt
Webinar
Webinar

Webcast mit Microsoft: Fit für die digitale Arbeitswelt

Die digitale Transformation und die Veränderung der Arbeitswelt ist längst in vielen Unternehmen und in den öffentlichen Einrichtungen angekommen. Dennoch stell...

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.

SharePoint Framework Client-Side Webparts mit React
Blog
Blog

SharePoint Framework Client-Side Webparts mit React

React ist ein Framework zur Erstellen von Benutzeroberflächen. In der SharePoint Online Entwicklung bietet es sich für die Entwicklung von Client-Side Webparts...

Jan
17
Webinar Azure DevOps und Docker Machine
Webinar
Webinar

Webinar Azure DevOps und Docker Machine

DevOps ist in aller Munde, doch was genau verbirgt sich eigentlich hinter dem so viel beschworenen Konzept der IT-Zusammenarbeit? Im Webinar am 17.01.2019 erfah...

Strukturen lernen und leben – Praxis Informationsarchitektur
Blog
Blog

Strukturen lernen und leben – Praxis Informationsarchitektur

Teil 1 – Strukturen lernen – Informationsarchitektur erfolgreich vertreten

Farben zur Optimierung des SharePoint-Kalender
Blog
Blog

Farben zur Optimierung des SharePoint-Kalender

Auch in SharePoint kann man Kategorien für Teamkalender-Einträge farblich abheben und damit die Lesbarkeit erhöhen. Wir zeigen Ihnen, wie das geht.

Die Micro-Info-Architektur
Blog
Blog

Die Micro-Info-Architektur

Vertiefung zum Thema Informationsarchitektur moderner Intranets mit SharePoint: Das Micro-Management.

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.

Sliding to heaven – A short story of a SPFx Slider Webpart
Blog
Blog

Sliding to heaven – A short story of a SPFx Slider Webpart

SharePoint Framework, kurz SPFx, ist eine zukunftsträchtige Technologie zur Erstellung von Webparts oder Extensions auf der Basis von TypeScript.