Dodawanie pakietów do projektu platformy .NET

  • 2 min

Platforma .NET udostępnia wiele podstawowych bibliotek obsługujących wiele funkcji, od zarządzania plikami przez protokół HTTP aż po kompresowanie plików. Istnieje też duży ekosystem bibliotek innych dostawców. Możesz zainstalować te biblioteki i korzystać z nich w aplikacji za pomocą narzędzia NuGet, czyli menedżera pakietów platformy .NET.

Na platformie .NET i w jej ekosystemie często używa się słowa zależność. Zależność pakietu to biblioteka innego dostawcy. Jest to fragment kodu wielokrotnego użytku, który wykonuje coś i który można dodać do aplikacji. Biblioteka innego dostawcy to coś, od czego działanie aplikacji jest zależne, dlatego nazywa się ją zależnością.

Bibliotekę innej firmy można traktować jako pakiet przechowywany w repozytorium. Pakiet składa się z co najmniej jednej biblioteki, którą można dodać do aplikacji, aby korzystać z jej funkcji.

W tym miejscu koncentrujemy się na zależnościach pakietów. Jednak projekt platformy .NET może mieć inne typy zależności oprócz zależności pakietów. W tym struktury, analizatory, odwołania do projektu i współużytkowane zależności projektu.

Ustalanie, czy jest potrzebny pakiet

Jak ustalić, czy w danym projekcie jest potrzebny pakiet? Jest to skomplikowane pytanie, które obejmuje kilka czynników:

  • Coraz lepszy kod: zadaj sobie pytanie, czy masz do czynienia z zadaniem, na przykład zabezpieczeniami i próbujesz zaimplementować uwierzytelnianie i autoryzację. Jest to zadanie, którego poprawne wykonanie w projekcie jest niezwykle ważne dla zapewnienia ochrony danych własnych i klienta. Dostępne są standardowe wzorce i biblioteki używane przez wielu deweloperów. Te biblioteki implementują funkcje, których prawdopodobnie zawsze potrzebujesz, a problemy są poprawiane w miarę ich powstawania. Najlepiej jest używać właśnie takich bibliotek, zamiast samodzielnie je tworzyć. Prawdopodobnie nie napiszesz również kodu, ponieważ istnieje tak wiele przypadków brzegowych, które należy wziąć pod uwagę.
  • Oszczędność czasu: prawdopodobnie większość rzeczy można utworzyć samodzielnie, takich jak biblioteki składników narzędzi lub interfejsu użytkownika, ale zajmuje to trochę czasu. Nawet jeśli wyniki są porównywalne z dostępnymi elementami, nie jest to dobre wykorzystanie czasu do replikowania pracy.
  • Konserwacja: wszystkie biblioteki i aplikacje wymagają konserwacji wcześniej lub później. Konserwacja obejmuje dodawanie nowych funkcji, ale również eliminowanie usterek. Czy jest to dobre wykorzystanie czasu lub czasu zespołu do utrzymania biblioteki, czy lepiej pozwolić zespołowi oprogramowania open source obsłużyć go?

Ocenianie pakietu

Przed zainstalowaniem biblioteki warto sprawdzić zależności, na których polega. Te zależności mogą zachęcić Cię do skorzystania z danego pakietu lub Cię od tego powstrzymać. Poniżej przedstawiono niektóre czynniki, które warto wziąć pod uwagę podczas wybierania zależności dla projektu:

  • Rozmiar: liczba zależności może spowodować powstanie dużego śladu. Jeśli masz ograniczoną przepustowość lub istnieją inne ograniczenia sprzętowe, może to być problem.
  • Licencjonowanie: musisz upewnić się, że licencja udzielona dla biblioteki obejmuje zamierzone użycie, niezależnie od tego, czy jest to użycie komercyjne, osobiste, czy akademickie.
  • Aktywna konserwacja: Może to być problem, jeśli pakiet opiera się na zależności, która nie jest aktywnie utrzymywana. Zależność może być przestarzała lub nie została zaktualizowana przez długi czas.

Aby dowiedzieć się więcej na temat pakietu przed jego instalacją, odwiedź stronę: https://www.nuget.org/packages/<package name>. Ten adres URL powoduje przejście do szczegółowej strony pakietu. Wybierz listę rozwijaną Zależności , aby zobaczyć, które pakiety korzystają z funkcji.

Sama liczba wymienionych zależności może nie oddawać całej prawdy. Po pobraniu pakietu może okazać się, że istnieje zależność pakietu obejmująca kilkadziesiąt pakietów. Dlaczego? Każdy pakiet ma listę zależności. Gdy uruchomisz polecenie dotnet add package <package name>, wszystkie zależności są przeszukiwane i pobierane, aby zapewnić, że będzie można użyć pakietu.

Instalowanie pakietu

Istnieje kilka sposobów instalowania pakietów. W programach Visual Studio i Visual Studio dla komputerów Mac dostępny jest wbudowany wiersz polecenia i graficzny interfejs użytkownika dla menedżera pakietów. Możesz ręcznie dodać odwołania do pakietu do pliku projektu lub zainstalować je za pomocą narzędzia interfejsu wiersza polecenia, takiego jak Paket lub interfejs wiersza polecenia platformy .NET Core.

W tym module używamy wbudowanego interfejsu wiersza polecenia platformy .NET Core do instalowania pakietów. Pakiet można dodać do projektu platformy .NET, wywołując polecenie w terminalu. Typowe polecenie instalacji wygląda następująco: dotnet add package <name of package>. Po uruchomieniu polecenia add package narzędzie wiersza polecenia łączy się z rejestrem globalnym, pobiera pakiet i umieszcza go w lokalizacji buforowanego folderu, gdzie jest dostępny do użycia dla wszystkich projektów.

Po zainstalowaniu i kompilacji projektu odwołania zostaną dodane do folderów debugowania lub wydania. Katalog projektu wygląda następująco:

-| bin/
---| Debug/
------| net3.1
--------| <files included in the dependency>

Znajdowanie pakietu

Indywidualni deweloperzy mogą korzystać z rejestru globalnego w witrynie NuGet.org, aby znajdować i pobierać pakiety, których potrzebują w swoich aplikacjach. Firmy mogą mieć opracowane strategie dotyczące tego, których pakietów można używać i gdzie można je znaleźć.

Zrzut ekranu przedstawiający witrynę NuGet.org z listą popularnych pakietów.

Pakiety mogą znajdować się w wielu różnych miejscach. Niektóre z tych źródeł mogą być publicznie dostępne, a niektóre mogą być ograniczone i dostępne tylko dla pracowników określonej firmy. Poniżej przedstawiono listę przykładowych miejsc, w których mogą znajdować się pakiety:

  • Rejestry: przykładem może być rejestr globalny, taki jak rejestr NuGet.org. Istnieje możliwość hostowania własnych rejestrów, które mogą być prywatne lub publiczne. Usługi takie jak GitHub i Azure DevOps udostępniają rejestry prywatne.
  • Pliki: pakiet można zainstalować z folderu lokalnego. Instalacja z pakietu jest powszechna, gdy próbujesz opracować własne biblioteki .NET i chcesz przetestować pakiet lokalnie. Lub z jakiegoś powodu nie chcesz używać rejestru.

Diagram przedstawiający relację między twórcami pakietów, hostami pakietów i użytkownikami pakietów.

Rejestr NuGet i narzędzie dotnet

Po uruchomieniu polecenia dotnet add package <name of dependency>platforma .NET przechodzi do rejestru globalnego o nazwie NuGet.org rejestru znajdującego się w https://nuget.org lokalizacji i wyszukuje kod do pobrania. Możesz również przeglądać tę stronę pod kątem pakietów, jeśli go odwiedzasz przy użyciu przeglądarki. Każdy pakiet ma dedykowaną witrynę internetową, do której można przejść.

Zrzut ekranu przedstawiający stronę docelową dla pakietu NuGet.

W tych witrynach znajdziesz informacje na temat lokalizacji kodu źródłowego. Możesz również znaleźć informacje, takie jak metryki dotyczące pobierania i informacje o konserwacji.

Zrzut ekranu przedstawiający informacje i metryki dotyczące pakietu NuGet.

Polecenia platformy .NET

Do tej pory przedstawiono sposób instalowania zależności przy użyciu interfejsu wiersza polecenia platformy .NET Core. Jednak to narzędzie pozwala robić o wiele więcej.

Interfejs wiersza polecenia platformy .NET Core udostępnia wiele poleceń. Polecenia te ułatwiają wykonywanie zadań takich jak instalowanie pakietów, tworzenie pakietów oraz inicjowanie projektów platformy .NET. Nie trzeba szczegółowo poznawać wszystkich poleceń. Rozpoczynając pracę na platformie .NET, prawdopodobnie będziesz używać tylko podzbioru tych poleceń. W miarę rozszerzania korzystania z platformy .NET możesz użyć większej liczby poleceń z różnych kategorii.

Aby zapamiętać, do czego służą polecenia, warto traktować je jako należące do różnych kategorii:

  • Zarządzanie zależnościami: polecenia w tej kategorii obejmują instalację, usuwanie, oczyszczanie po instalacjach pakietów i aktualizacje pakietów.
  • Uruchamianie programów: narzędzie .NET Core może ułatwić zarządzanie przepływami w tworzeniu aplikacji. Przykłady przepływów aplikacji to uruchamianie testów, kompilowanie kodu lub uruchamianie poleceń migracji w celu uaktualnienia projektów.
  • Tworzenie i publikowanie pakietów: Kilka poleceń ułatwia wykonywanie zadań, takich jak tworzenie skompresowanego pakietu i wypychanie pakietu do rejestru.

Aby uzyskać szczegółową listę wszystkich poleceń, można wprowadzić polecenie dotnet --help w terminalu.

Jak zainstalować pakiet

Użyj polecenia , dotnet add package <dependency name> aby zainstalować normalną zależność, która ma być używana jako część aplikacji.

Uwaga

Niektóre pakiety można zainstalować globalnie. Te pakiety nie mają być importowane do projektu. Z tego powodu wiele pakietów globalnych jest narzędziami interfejsu wiersza polecenia lub szablonami. Te narzędzia globalne można też zainstalować z poziomu repozytorium pakietów. Zainstaluj narzędzia przy użyciu polecenia dotnet tool install <name of package>. Zainstaluj szablony przy użyciu polecenia dotnet new -i <name of package>.

Po instalacji

Zainstalowane pakiety są wymienione w dependencies sekcji .csproj pliku. Jeśli chcesz zobaczyć, które pakiety znajdują się w folderze, możesz wprowadzić polecenie dotnet list package.

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

To polecenie wyświetla tylko pakiety najwyższego poziomu, a nie zależności tych pakietów, które nazywamy pakietami przechodnimi. To polecenie jest miłe dla szybkiego wyglądu. Jeśli potrzebujesz bardziej szczegółowego widoku, możesz wyświetlić wszystkie pakiety przejściowe. W takim list przypadku polecenie wygląda następująco:

dotnet list package --include-transitive

Uwzględnienie przechodnich umożliwia wyświetlanie zależności wraz ze wszystkimi zainstalowanymi pakietami. Jeśli uruchomisz polecenie dotnet list package --include-transitive, możesz uzyskać następujące dane wyjściowe:

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

   Transitive Package               Resolved
   > Humanizer.Core                 2.7.9
   > Humanizer.Core.af              2.7.9
   > Humanizer.Core.ar              2.7.9
   > Humanizer.Core.bg              2.7.9
   > Humanizer.Core.bn-BD           2.7.9
   > Humanizer.Core.cs              2.7.9
   ...

Przywracanie zależności

Podczas tworzenia lub klonowania projektu dołączone zależności nie są pobierane ani instalowane do momentu skompilowania projektu. Możesz ręcznie przywrócić zależności i narzędzia specyficzne dla projektu określone w pliku projektu, uruchamiając dotnet restore polecenie . W większości przypadków nie trzeba jawnie używać tego polecenia. Przywracanie nuGet jest uruchamiane niejawnie, jeśli to konieczne, podczas uruchamiania poleceń, takich jak new, buildi run.

Czyszczenie zależności

Wcześniej czy później znajdziesz się w sytuacji, w której dany pakiet nie będzie już potrzebny. Możesz też zdać sobie sprawę, że zainstalowany pakiet nie jest potrzebny. Być może znalazłeś taki, który lepiej realizuje zadanie. Bez względu na przyczynę, zechcesz wtedy usunąć zależności, które nie są już używane. Takie oczyszczanie pozwala zachować porządek. Ponadto zależności zajmują miejsce.

Aby usunąć pakiet z projektu, użyj remove polecenia w następujący sposób: dotnet remove package <name of dependency>. To polecenie usuwa pakiet z pliku projektu .csproj .