Zentrale NuGet-Paketverwaltung

Für alle NuGet -Konsumenten gibt es eine neue und interessante Funktion: Die zentrale Paketverwaltung ! Sie erlaubt die Pflege der zu verwendenden NuGet-Paketversionen an zentraler Stelle in einer einzigen Datei. Die Funktionalität kann bereits mit aktuellen Release-Entwicklungswerkzeugen verwendet werden, befindet sich jedoch noch im Vorschaustatus.

Mittels <PackageVersion> kann in einer Directory.Packages.props-Datei angegeben werden, welche Versionen der Pakete verwendet werden sollen:

<Project>

  <ItemGroup>
    <PackageVersion Include="Microsoft.Data.SqlClient" Version="5.0.0" />
  </ItemGroup>

</Project>

Anschließend kann in einer Projektdatei bei einer <PackageReference> das Version-Attribut weggelassen werden, um die zentral vorgegebene zu nutzen:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Data.SqlClient" />
    <PackageReference Include="StackExchange.Redis" VersionOverride="2.6.48" />
  </ItemGroup>

</Project>

Die Directory.Packages.props-Datei gilt für alle Projekte im selben oder in untergeordneten Verzeichnissen (unabhängig von Projektmappen!). Mittels des VersionOverride-Attributs können Projekte von den zentral erfassten abweichende Versionen für Pakete vorgeben.

Aktiviert wird die zentrale Paketverwaltung über die MSBuild -Eigenschaft <ManagePackageVersionsCentrally> innerhalb einer <PropertyGroup>. Diese Eigenschaft kann (wie im Beispiel) für einzelne Projekte oder über die Directory.Packages.props-Datei für mehrere Projekte auf einmal gesetzt werden.

Achtung: Sobald die zentrale Paketverwaltung für ein Projekt aktiviert ist, sind nur noch <PackageReference>-Elemente komplett ohne Versionsnummern oder mit VersionOverride-Attribut gültig. Wenn nur das Version-Attribut verwendet wird, führt dies zu einem Fehler. Interessanterweise ist es kein Fehler, wenn beide Attribute vorhanden sind – in diesem Fall gewinnt jedoch das Version-Attribut!

Trotz zentraler Paketverwaltung muss nicht für alle Pakete eine Version in einer Directory.Packages.props-Datei gepflegt werden; es ist weiterhin möglich, neue Pakete mittels <PackageReference> in der Projektdatei zu erfassen. Dies ist etwa im obigen Beispiel bei StackExchange Redis zu sehen.

Tooling-Kompatibilität

Die diesen Monat erschiene Visual Studio Version 17.3 ist zu empfehlen. Offiziell unterstützt wurde die Funktionalität zwar bereits mit 17.2 (siehe Ankündigung ), allerdings konnte die enthaltene NuGet-UI die zentrale Versionsdatei noch nicht verändern. Ab 17.3 werden alle Paketänderungen für Projekte mit zentraler Verwaltung in der Directory.Packages.props-Datei umgesetzt. Nur noch bei Verwendung des VersionOverride-Attributs gibt es Schwierigkeiten, die manuelles Eingreifen erfordern. Eine grafische Oberfläche für die direkte Pflege der Directory.Packages.props-Datei fehlt jedoch weiterhin.

Von der Verwendung des .NET SDK für die Paketverwaltung ist hingegen noch abzuraten. Auch in der Version 7.0.0-preview.7 deckt sich das Verhalten mit Visual Studio 17.2 und führt nicht zu den gewünschten Ergebnissen.

Paketquellenzuordnung

Falls mehr als eine NuGet-Paketquelle konfiguriert ist (etwa ein lokaler Paketfeed ), müssen in einer NuGet.Config-Datei Regeln definiert werden, um für jedes Paket anhand des Namens die zu verwendende Quelle zuzuordnen. Details zu dieser Konfiguration sind in der Microsoft-Dokumentation zu finden. Sollten mehrere NuGet.Config-Dateien zum Einsatz kommen, ist zusätzlich die Dokumentation zur Vererbung der Konfigurationseinträge zu empfehlen (beim Aufruf von nuget.exe ist das Arbeitsverzeichnis relevant, nicht das Verzeichnis des Projekts oder der Projektmappe!).

Fazit

Die zentrale Paketverwaltung kann bei vielen Projekten, die die gleichen NuGet-Paketversionen verwenden müssen (etwa, weil sie gemeinsam von anderen Projekten referenziert werden), eine Erleichterung sein. Die Aktualisierung der Pakete wird jedoch komplizierter, da nicht direkt ersichtlich ist, welche Projekte betroffen sind und somit getestet werden müssen.

Wenn es keine Anforderung ist, dass die Paketversionen projektübergreifend übereinstimmen, bietet die zentrale Paketverwaltung keinen Vorteil und auf sie zu verzichten ist besser, um leichter die Pakete einzelner Projekte verändern zu können.

Somit ist die zentrale Paketverwaltung kein Must-have, aber ein für manche Situationen nützliches Werkzeug.