Wprowadzenie do narzędzia NuGet
Podstawowym narzędziem dla każdej nowoczesnej platformy deweloperów jest mechanizm, za pomocą którego deweloperzy mogą tworzyć, udostępniać i wykorzystywać przydatny kod. Często taki kod jest dołączany do "pakietów", które zawierają skompilowany kod (jako biblioteki DLL) wraz z inną zawartością wymaganą w projektach korzystających z tych pakietów.
W przypadku platformy .NET (w tym platformy .NET Core) obsługiwany przez firmę Microsoft mechanizm udostępniania kodu jest NuGet, który definiuje sposób tworzenia, hostowania i korzystania pakietów dla platformy .NET oraz udostępnia narzędzia dla każdej z tych ról.
Po prostu pakiet NuGet to pojedynczy plik ZIP z rozszerzeniem .nupkg zawierającym skompilowany kod (DLL), inne pliki powiązane z tym kodem oraz opisowy manifest zawierający informacje takie jak numer wersji pakietu. Deweloperzy, którzy mają kod do udostępnienia, tworzą pakiety i publikują je na hoście publicznym lub prywatnym. Użytkownicy pakietów uzyskują te pakiety z odpowiednich hostów, dodają je do swoich projektów, a następnie wywołają funkcjonalność pakietu w kodzie projektu. Następnie program NuGet obsługuje wszystkie szczegóły pośrednie.
Ponieważ pakiet NuGet obsługuje hosty prywatne wraz z publicznym hostem nuget.org, możesz użyć pakietów NuGet do udostępniania kodu, który jest przeznaczony wyłącznie dla organizacji lub grupy roboczej. Możesz również używać pakietów NuGet jako wygodnego sposobu na organizowanie własnego kodu do użytku wyłącznie we własnych projektach. Krótko mówiąc, pakiet NuGet jest współużytkową jednostką kodu, ale nie wymaga ani nie oznacza żadnego konkretnego środka udostępniania.
Przepływ pakietów między twórcami, hostami i użytkownikami
W roli hosta publicznego sam NuGet utrzymuje centralne repozytorium ponad 100 000 unikatowych pakietów w nuget.org. Te pakiety są codziennie wykorzystywane przez miliony deweloperów platformy .NET/.NET Core. Pakiet NuGet umożliwia również hostowanie pakietów prywatnie w chmurze (np. w usłudze Azure DevOps), w sieci prywatnej, a nawet tylko w lokalnym systemie plików. Dzięki temu te pakiety są dostępne tylko dla tych deweloperów, którzy mają dostęp do hosta, co daje możliwość udostępniania pakietów określonym grupom odbiorców. Opcje zostały wyjaśnione Hosting własnych kanałów informacyjnych NuGet. Za pomocą opcji konfiguracji można również kontrolować dokładnie, do których hostów można uzyskiwać dostęp na dowolnym komputerze, dzięki czemu pakiety są uzyskiwane z określonych źródeł, a nie z repozytorium publicznego, takiego jak nuget.org.
Niezależnie od jego charakteru host służy jako punkt połączenia między twórcami pakietów a konsumentami pakietów . Twórcy tworzą przydatne pakiety NuGet i publikują je na hoście. Następnie użytkownicy wyszukują przydatne i zgodne pakiety na hostach z ułatwieniami dostępu, pobierając i włączając te pakiety w swoich projektach. Po zainstalowaniu w projekcie interfejsy API pakietów są dostępne dla pozostałej części kodu projektu.
Kompatybilność docelowa pakietu
Pakiet "zgodny" oznacza, że zawiera zestawy utworzone dla co najmniej jednej docelowej platformy .NET, która jest zgodna z platformą docelową projektu zużywanego. Deweloperzy mogą tworzyć pakiety specyficzne dla jednej struktury, podobnie jak w przypadku kontrolek platformy UWP, lub mogą obsługiwać szerszy zakres celów. Aby zmaksymalizować zgodność pakietu, deweloperzy celują w .NET Standard, który może być konsumowany przez wszystkie projekty .NET i .NET Core. Jest to najbardziej wydajny sposób zarówno dla twórców, jak i odbiorców, ponieważ pojedynczy pakiet (zwykle zawierający pojedynczy zestaw) działa dla wszystkich projektów zużywających.
Deweloperzy pakietów, którzy potrzebują interfejsów API spoza .NET Standard, tworzą oddzielne biblioteki dla różnych platform docelowych, które chcą obsługiwać, i dołączają wszystkie te biblioteki do tego samego pakietu (proces ten nazywany jest "wielokrotnym celowaniem"). Gdy użytkownik zainstaluje taki pakiet, narzędzie NuGet wyodrębnia tylko te zestawy, które są wymagane przez projekt. Minimalizuje to ślad pakietu w końcowej aplikacji i/lub zestawach utworzonych przez ten projekt. Pakiet wieloplatformowy jest oczywiście trudniejszy do utrzymania przez jego twórcę.
Notatka
Aby uzyskać wskazówki dotyczące składników aplikacji a bibliotek wielokrotnego użytku, zobacz dokumentację platformy .NET Standard w temacie.
Narzędzia NuGet
Oprócz obsługi hostingu pakiet NuGet udostępnia również różne narzędzia używane zarówno przez twórców, jak i użytkowników. Zobacz Instalowanie narzędzi klienckich NuGet, aby dowiedzieć się, jak uzyskać określone narzędzia.
| Narzędzie | Platformy | Odpowiednie scenariusze | Opis |
|---|---|---|---|
| interfejs wiersza polecenia dotnet | Wszystko | Tworzenie, zużycie | Narzędzie interfejsu wiersza polecenia dla bibliotek .NET Core i .NET Standard oraz projektów w stylu zestawu SDK przeznaczonych dla platformy .NET Framework (zobacz atrybut zestawu SDK). Zapewnia niektóre funkcje CLI NuGet bezpośrednio w zestawie narzędzi platformy .NET Core. Podobnie jak w przypadku CLI nuget.exe, CLI dotnet nie współpracuje z projektami programu Visual Studio. |
| nuget.exe interfejsu wiersza polecenia | Wszystko | Tworzenie, zużycie | Narzędzie CLI dla bibliotek platformy .NET Framework i projektów nie-SDK celujących w biblioteki .NET Standard. Udostępnia wszystkie funkcje NuGet, przy czym niektóre polecenia są związane specjalnie z twórcami pakietów, niektóre stosują się tylko do użytkowników, a inne do obu grup. Na przykład twórcy pakietów używają polecenia nuget pack, aby utworzyć pakiet z różnych zestawów i powiązanych plików, użytkownicy pakietów używają nuget install do dołączania pakietów do folderu projektu, a wszyscy używają nuget config do ustawiania zmiennych konfiguracji NuGet. Jako narzędzie niezależne od platformy interfejs wiersza polecenia NuGet nie współdziała z projektami programu Visual Studio. |
| Konsola Menedżera Pakietów | Program Visual Studio w systemie Windows | Konsumpcja | Udostępnia polecenia programu PowerShell do instalowania pakietów i zarządzania nimi w projektach programu Visual Studio. |
| interfejs użytkownika menedżera pakietów | Program Visual Studio w systemie Windows | Konsumpcja | Zapewnia łatwy w użyciu interfejs użytkownika do instalowania pakietów i zarządzania nimi w projektach programu Visual Studio. |
| Zarządzanie interfejsem użytkownika NuGet | Visual Studio dla komputerów Mac | Konsumpcja | Zapewnij łatwy w użyciu interfejs użytkownika do instalowania pakietów i zarządzania nimi w projektach programu Visual Studio dla komputerów Mac. |
| MSBuild | Windows | Tworzenie, zużycie | Umożliwia tworzenie pakietów i przywracanie pakietów używanych w projekcie bezpośrednio za pośrednictwem łańcucha narzędzi MSBuild. |
Jak widać, narzędzia NuGet, z którymi pracujesz, są bardzo zależne od tego, czy tworzysz, zużywasz, czy publikujesz pakiety, a także od platformy, na której pracujesz. Twórcy pakietów są zwykle również konsumentami, ponieważ opierają się na funkcjach, które istnieją w innych pakietach NuGet. I te pakiety, oczywiście, mogą z kolei zależeć od innych.
Aby uzyskać więcej informacji, zacznij od artykułów o przepływie pracy tworzenia pakietów i oraz przepływie pracy użycia pakietów i.
Zarządzanie zależnościami
Możliwość łatwego opierania się na pracy innych jest jedną z najpotężniejszych funkcji systemu zarządzania pakietami. W związku z tym większość funkcji NuGet zarządza tym drzewem zależności lub "grafem" w imieniu projektu. Mówiąc prościej, powinieneś martwić się tylko o te pakiety, których bezpośrednio używasz w projekcie. Jeśli którykolwiek z tych pakietów korzysta z innych pakietów (co z kolei może korzystać z innych), NuGet zajmuje się wszystkimi zależnościami na poziomie podrzędnym.
Na poniższej ilustracji przedstawiono projekt, który zależy od pięciu pakietów, które z kolei zależą od wielu innych.
Zwróć uwagę, że niektóre pakiety są wyświetlane wiele razy na wykresie zależności. Na przykład istnieją trzech różnych odbiorców pakietu B, a każdy odbiorca może również określić inną wersję dla tego pakietu (nie pokazano). Jest to typowe wystąpienie, szczególnie w przypadku powszechnie używanych pakietów. Pakiet NuGet na szczęście wykonuje całą złożoną pracę, aby dokładnie określić, która wersja pakietu B spełnia wymagania wszystkich użytkowników. Narzędzie NuGet wykonuje to samo dla wszystkich innych pakietów, niezależnie od tego, jak głęboki jest graf zależności.
Aby uzyskać więcej informacji na temat sposobu, w jaki narzędzie NuGet realizuje rozwiązywanie zależności, zobacz rozwiązywanie zależności.
Śledzenie referencji i przywracanie pakietów
Ponieważ projekty mogą łatwo przenosić się między komputerami deweloperów, repozytoriami kontroli źródła, serwerami kompilacji itd., bardzo niepraktyczne jest utrzymywanie zestawów binarnych pakietów NuGet bezpośrednio powiązanych z projektem. Spowodowałoby to, że każda kopia projektu byłaby nadmiernie rozbudowana (a tym samym marnuje miejsce w repozytoriach systemu kontroli wersji). Bardzo trudno byłoby również zaktualizować pliki binarne pakietu do nowszych wersji, ponieważ aktualizacje musiałyby być stosowane we wszystkich kopiach projektu.
Zamiast tego program NuGet utrzymuje prostą listę odwołań pakietów, od których zależy projekt, w tym zarówno zależności najwyższego poziomu, jak i zależności niższego poziomu. Oznacza to, że za każdym razem, gdy instalujesz pakiet z jakiegoś hosta w projekcie, nuGet rejestruje identyfikator pakietu i numer wersji na liście referencyjnej. (Oczywiście odinstalowanie pakietu spowoduje usunięcie go z listy). Następnie NuGet umożliwia przywrócenie wszystkich referencyjnych pakietów na żądanie, jak opisano w Przywracanie pakietu.
Przy użyciu tylko listy referencyjnej pakiet NuGet może następnie ponownie zainstalować — czyli przywrócić— wszystkie te pakiety z hostów publicznych i/lub prywatnych w dowolnym późniejszym czasie. W przypadku zatwierdzania projektu do kontroli źródła lub udostępniania go w inny sposób należy uwzględnić tylko listę referencyjną i wykluczyć wszystkie pliki binarne pakietu (zobacz Packages and source control.)
Komputer, który odbiera projekt, taki jak serwer kompilacji uzyskujący kopię projektu w ramach zautomatyzowanego systemu wdrażania, po prostu prosi NuGet o przywrócenie zależności, gdy są potrzebne. Systemy kompilacji, takie jak Azure DevOps, udostępniają kroki „przywracania NuGet” specjalnie w tym celu. Podobnie, gdy deweloperzy uzyskują kopię projektu (jak podczas klonowania repozytorium), mogą wywołać polecenie, takie jak nuget restore (interfejs wiersza polecenia NuGet), dotnet restore (interfejs wiersza polecenia dotnet) lub Install-Package (konsola Menedżera pakietów), aby uzyskać wszystkie niezbędne pakiety. Program Visual Studio, ze swej strony, automatycznie przywraca pakiety podczas kompilowania projektu (pod warunkiem, że automatyczne przywracanie jest włączone, zgodnie z opisem w przywracanie pakietów).
Oczywiście podstawową rolą NuGet, w której deweloperzy są zainteresowani, jest utrzymanie tej listy referencyjnej w imieniu projektu i zapewnienie środków efektywnego przywracania (i aktualizowania) tych pakietów, do których się odwołuje. Ta lista jest przechowywana w jednym z dwóch formatów zarządzania pakietami , ponieważ są one nazywane:
PackageReference (lub "odwołania do pakietów w plikach projektu") | (NuGet 4.0+) Utrzymuje listę zależności najwyższego poziomu projektu bezpośrednio w pliku projektu, więc nie jest potrzebny żaden oddzielny plik. Skojarzony plik,
obj/project.assets.json, jest generowany dynamicznie w celu zarządzania ogólnym grafem zależności pakietów używanych przez projekt wraz ze wszystkimi zależnościami na poziomie podrzędnym. Funkcja PackageReference jest zawsze używana przez projekty platformy .NET Core.packages.config: (NuGet 1.0+) Plik XML, który utrzymuje płaską listę wszystkich zależności w projekcie, w tym zależności innych zainstalowanych pakietów. Zainstalowane lub przywrócone pakiety są przechowywane w folderzepackages.
Format zarządzania pakietami jest używany w dowolnym projekcie zależy od typu projektu i dostępnej wersji pakietu NuGet (i/lub Visual Studio). Aby sprawdzić, jaki format jest używany, po prostu poszukaj packages.config w katalogu głównym projektu po zainstalowaniu pierwszego pakietu. Jeśli nie masz tego pliku, poszukaj w pliku projektu bezpośrednio elementu <PackageReference>.
Jeśli masz wybór, zalecamy użycie funkcji PackageReference.
packages.config jest utrzymywany dla celów historycznych i nie jest już aktywnie rozwijany.
Napiwek
Różne polecenia interfejsu wiersza polecenia nuget.exe, takie jak nuget install, nie są automatycznie dodawane do listy referencyjnej. Lista jest aktualizowana podczas instalowania pakietu za pomocą programu Visual Studio Package Manager (interfejs użytkownika lub konsoli) oraz przy użyciu interfejsu wiersza polecenia dotnet.exe.
Co jeszcze robi NuGet?
Do tej pory znasz następujące cechy narzędzia NuGet:
- NuGet udostępnia centralne repozytorium nuget.org z obsługą prywatnego hostingu.
- Pakiet NuGet udostępnia narzędzia potrzebne deweloperom do tworzenia, publikowania i używania pakietów.
- Co najważniejsze, NuGet utrzymuje listę referencyjną pakietów używanych w projekcie oraz możliwość przywracania i aktualizowania tych pakietów z tej listy.
Aby te procesy działały wydajnie, pakiet NuGet wykonuje pewne optymalizacje za kulisami. W szczególności NuGet zarządza pamięcią podręczną pakietów i folderem pakietów globalnych w celu skrótu instalacji i ponownej instalacji. Pamięć podręczna pozwala uniknąć pobierania pakietu, który został już zainstalowany na maszynie. Folder pakietów globalnych umożliwia wielu projektom współużytkowania tego samego zainstalowanego pakietu, co zmniejsza całkowity ślad NuGet na komputerze. Folder pamięci podręcznej i pakietów globalnych jest również bardzo przydatny w przypadku częstego przywracania większej liczby pakietów, jak na serwerze kompilacji. Aby uzyskać więcej informacji na temat tych mechanizmów, zobacz Zarządzanie globalnymi pakietami i folderami pamięci podręcznej.
W ramach pojedynczego projektu narzędzie NuGet zarządza ogólnym grafem zależności, który ponownie obejmuje rozpoznawanie wielu odwołań do różnych wersji tego samego pakietu. Często projekt przyjmuje zależność od co najmniej jednego pakietu, które mają te same zależności. Niektóre z najbardziej przydatnych pakietów narzędzi na nuget.org są stosowane przez wiele innych pakietów. W całym grafie zależności można łatwo mieć dziesięć różnych odwołań do różnych wersji tego samego pakietu. Aby uniknąć wprowadzenia wielu wersji tego pakietu do samej aplikacji, pakiet NuGet sortuje, która wersja może być używana przez wszystkich użytkowników. (Aby uzyskać więcej informacji, zobacz Rozwiązywanie zależności.)
Poza tym nuGet utrzymuje wszystkie specyfikacje związane ze strukturą pakietów (w tym lokalizacji i symbolami debugowania ) oraz sposobem ich odwołań (w tym zakresami wersji i wersjami wstępnymi ). NuGet udostępnia również różne interfejsy API do programowego współdziałania ze swoimi usługami i zapewnia obsługę deweloperów, którzy piszą rozszerzenia programu Visual Studio i szablony projektów.
Poświęć chwilę, aby przejrzeć spis treści tej dokumentacji, a zobaczysz wszystkie te możliwości przedstawione tam, wraz z notatkami wydań sięgającymi początków NuGet.
Powiązane wideo
Znajdź filmy NuGet na Channel 9 i YouTube.
Komentarze, wkłady i problemy
Na koniec bardzo mile widziane komentarze i współtworzenie tej dokumentacji — wystarczy wybrać Feedback i Edytować polecenia w górnej części dowolnej strony lub odwiedzić repozytorium dokumentów i listę problemów z dokumentacją w witrynie GitHub.
Zachęcamy również do udziału w programie NuGet za pośrednictwem różnych repozytoriów GitHub; Problemy z pakietem NuGet można znaleźć w https://github.com/NuGet/home/issues.
Ciesz się doświadczeniem NuGet!