Ein eigener NuGet-Feed im Heimnetz
- Matt
Vor Jahren habe ich hier über meinen günstigen Git-Server auf einer alten QNAP geschrieben, und später darüber, wie man ein NuGet-Package erstellt. Beides trifft sich an einer Stelle: Wohin mit Paketen, die man in mehreren eigenen Projekten braucht, aber nicht auf nuget.org veröffentlichen will?
Die Antwort ist unspektakulärer, als man denkt. Ein NuGet-Feed kann ein Ordner sein.
Ordner als Quelle
Ein Verzeichnis auf dem NAS reicht aus:
dotnet nuget add source \\nas\pakete --name Heimnetz
Veröffentlicht wird mit demselben Befehl wie sonst, nur mit dem Ordner als Ziel:
dotnet pack -c Release
dotnet nuget push bin/Release/MeineBib.1.2.0.nupkg --source Heimnetz
Kein Server, kein Dienst, keine Zugangsdaten. Solange die Freigabe erreichbar ist, funktioniert Wiederherstellen und Installieren wie gewohnt. Für ein bis zwei Rechner ist das die ganze Lösung.
Ein Detail, das man wissen muss: Bei einem Ordner-Feed gibt es keine Versionsverwaltung im Hintergrund. Eine Version, die einmal dort liegt, bleibt genau so liegen, und wenn man dieselbe Versionsnummer noch einmal schiebt, bekommt man je nach Client eine Fehlermeldung oder stillschweigend das alte Paket aus dem lokalen Cache. Beim Entwickeln also lieber mit Vorabversionen arbeiten:
dotnet pack -c Release --version-suffix "alpha.$(date +%Y%m%d%H%M)"
Sonst debuggt man irgendwann eine Änderung, die gar nicht angekommen ist. Das kostet garantiert einmal einen Abend.
Konfiguration ins Projekt
Sinnvoller als eine globale Quelle ist eine nuget.config neben der Solution, damit die Einstellung mit dem Projekt wandert:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="Heimnetz" value="\\nas\pakete" />
</packageSources>
</configuration>
Das <clear /> am Anfang ist wichtiger, als es aussieht. Ohne diese Zeile kommen die Quellen aus der Benutzerkonfiguration dazu, und dann baut das Projekt auf dem eigenen Rechner, aber nicht auf dem Buildserver.
Package Source Mapping
Der Teil, den ich am längsten übersehen habe. Standardmäßig fragt NuGet bei allen Quellen nach allen Paketen. Heißt: Auch für MeineFirma.Interna geht eine Anfrage an nuget.org. Legt dort jemand ein Paket mit demselben Namen an, kann er einem Code unterschieben.
Dagegen hilft eine feste Zuordnung:
<packageSourceMapping>
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
<packageSource key="Heimnetz">
<package pattern="MeineBib.*" />
</packageSource>
</packageSourceMapping>
Ab da werden Pakete mit dem eigenen Präfix ausschließlich lokal gesucht. Für ein Heimnetz mag das übertrieben wirken, aber es kostet vier Zeilen, und im Firmenkontext ist es schlicht Pflicht.
Wann der Ordner nicht mehr reicht
Sobald mehrere Leute veröffentlichen, will man Symbolpakete, oder soll von außerhalb des Netzes gebaut werden, ist ein richtiger Feed dran. BaGet läuft als Container und kann genau das, GitHub Packages ist bei einem ohnehin dort liegenden Repository der kürzere Weg.
Für den Fall, für den ich es gebaut habe, also eine Handvoll eigener Bibliotheken auf zwei Rechnern, ist die Freigabe aber unschlagbar. Sie fällt nicht aus, sie braucht keine Wartung, und ein Backup hat sie durch das NAS ohnehin.