NuGet

NuGet jest menedżerem pakietów dla ekosystemu platformy .NET i jest podstawowym sposobem odnajdywania i uzyskiwania bibliotek open source platformy .NET. NuGet.org, bezpłatna usługa oferowana przez firmę Microsoft do hostowania pakietów NuGet, jest hostem podstawowym publicznych pakietów NuGet, ale można publikować w niestandardowych usługach NuGet, takich jak MyGet i Azure Artifacts.

Tworzenie pakietu NuGet

Pakiet NuGet (*.nupkg) to plik zip zawierający zestawy .NET i skojarzone metadane.

Istnieją dwa główne sposoby tworzenia pakietu NuGet. Nowszym i zalecanym sposobem jest utworzenie pakietu na podstawie projektu w stylu zestawu SDK (pliku projektu, którego zawartość zaczyna się od <Project Sdk="Microsoft.NET.Sdk">). Zestawy i obiekty docelowe są automatycznie dodawane do pakietu, a pozostałe metadane są dodawane do pliku MSBuild, na przykład nazwa pakietu i numer wersji. Kompilowanie za pomocą polecenia dotnet pack zwraca plik *.nupkg zamiast zestawów.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AssemblyName>Contoso.Api</AssemblyName>
    <PackageVersion>1.1.0</PackageVersion>
    <Authors>John Doe</Authors>
  </PropertyGroup>
</Project>

Starszy sposób tworzenia pakietu NuGet dotyczy pliku *.nuspec i narzędzia wiersza polecenia nuget.exe. Plik nuspec zapewnia świetną kontrolę, ale należy dokładnie określić zestawy i obiekty docelowe, które mają zostać uwzględnione w ostatnim pakiecie NuGet. Łatwo jest popełnić błąd lub zapomnieć o aktualizacji nuspec podczas wprowadzania zmian. Zaletą narzędzia nuspec jest użycie go do tworzenia pakietów NuGet dla struktur, które nie obsługują jeszcze pliku projektu w stylu zestawu SDK.

✔️ ROZWAŻ użycie pliku projektu w stylu zestawu SDK w celu utworzenia pakietu NuGet.

Zależności pakietów

Zależności pakietów NuGet są szczegółowo omówione w artykule Zależności .

Ważne metadane pakietu NuGet

Pakiet NuGet obsługuje wiele właściwości metadanych . Poniższa tabela zawiera podstawowe metadane, które powinny zawierać każdy pakiet w NuGet.org:

✔️ ROZWAŻ wybranie nazwy pakietu NuGet z prefiksem spełniającym kryteria rezerwacji prefiksu NuGet kryteriów.

✔️ Używaj odnośnika HTTPS dla ikony pakietu.

Witryny, takie jak NuGet.org, są uruchamiane z włączonym protokołem HTTPS, a wyświetlanie obrazu innego niż HTTPS spowoduje utworzenie ostrzeżenia o mieszanej zawartości.

✔️ Należy użyć obrazu ikony pakietu o rozmiarze 64x64 z przezroczystym tłem, aby uzyskać najlepsze wyniki wyświetlania.

✔️ ROZWAŻ skonfigurowanie Source Link w celu dodania metadanych kontroli wersji do zestawów programistycznych i pakietu NuGet.

Link źródłowy automatycznie dodaje metadane RepositoryUrl i RepositoryType do pakietu NuGet. Link źródłowy dodaje również informacje o dokładnym kodzie źródłowym, z którego utworzono pakiet. Na przykład pakiet utworzony na podstawie repozytorium Git będzie miał dodany skrót zatwierdzenia jako metadane.

Pakiety wersji wstępnej

Pakiety NuGet z sufiksem wersji są uznawane za wersję przedprodukcyjną. Domyślnie interfejs użytkownika Menedżera pakietów NuGet wyświetla stabilne wersje, chyba że użytkownik zdecyduje się na pakiety w wersji wstępnej, co czyni pakiety wersji wstępnej idealnym rozwiązaniem do ograniczonego testowania użytkowników.

<PackageVersion>1.0.1-beta1</PackageVersion>

✔️ Opublikuj pakiet w wersji wstępnej podczas testowania, podglądu lub eksperymentowania.

✔️ Publikuj stabilny pakiet, gdy jest gotowy, aby inne stabilne pakiety mogły się do niego odwoływać.

Pakiety symboli

Pliki symboli (*.pdb) są tworzone przez kompilator .NET wraz z modułami. Pliki symboli przyporządkowują punkty wykonywania do oryginalnego kodu źródłowego, aby można było śledzić kod źródłowy podczas jego działania za pomocą debugera. NuGet obsługuje generowanie oddzielnego pakietu symboli (*.snupkg), który zawiera pliki symboli obok głównego pakietu zawierającego zestawy .NET. Chodzi o to, że pakiety symboli są hostowane na serwerze symboli i są pobierane tylko przez narzędzie, takie jak Program Visual Studio na żądanie.

NuGet.org hostuje własne repozytorium serwera symboli . Deweloperzy mogą używać symboli opublikowanych na serwerze symboli NuGet.org, dodając https://symbols.nuget.org/download/symbols do źródeł symboli w programie Visual Studio.

Alternatywą do utworzenia pakietu symboli jest osadzanie plików symboli w głównym pakiecie NuGet. Główny pakiet NuGet będzie większy, ale osadzone pliki symboli oznaczają, że deweloperzy nie muszą konfigurować serwera symboli NuGet.org. Jeśli tworzysz pakiet NuGet przy użyciu projektu w stylu zestawu SDK, możesz osadzić pliki symboli, ustawiając właściwość AllowedOutputExtensionsInPackageBuildOutputFolder:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
    <!-- Include symbol files (*.pdb) in the built .nupkg -->
    <AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
  </PropertyGroup>
</Project>

Wadą osadzania plików symboli jest zwiększenie rozmiaru pakietu o około 30% dla bibliotek .NET kompilowanych przy użyciu projektów w stylu SDK. Jeśli rozmiar pakietu jest problemem, zamiast tego należy opublikować symbole w pakiecie symboli.

✔️ ROZWAŻ publikowanie symboli jako pakietu symboli (*.snupkg) do NuGet.org

Pakiety symboli (*.snupkg) zapewniają deweloperom dobre środowisko debugowania na żądanie bez zwiększania rozmiaru głównego pakietu i bez wpływu na wydajność przywracania dla tych, którzy nie planują debugować pakietów NuGet.

Zastrzeżeniem jest to, że użytkownicy mogą potrzebować znaleźć i skonfigurować serwer symboli NuGet w swoim środowisku IDE (jako konfiguracja jednorazowa), aby uzyskać pliki symboli. Program Visual Studio 2019 w wersji 16.1 dodał serwer symboli nuGet.org do listy domyślnych serwerów symboli.