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 to 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 .nupkg rozszerzeniem zawierającym skompilowany kod (DLL), inne pliki powiązane z tym kodem oraz opisowy manifest zawierający informacje takie jak numer wersji pakietu. Deweloperzy z kodem do udostępniania pakietów i publikowania ich 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żyć pakietów NuGet jako wygodnego sposobu, aby uwzględnić własny kod do użycia w niczym, ale 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 w temacie 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.

Zgodność elementów docelowych pakietów

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 korzystają z platformy .NET Standard, z której mogą korzystać wszystkie projekty platformy .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 wymagają interfejsów API spoza platformy .NET Standard, z drugiej strony tworzą oddzielne zestawy dla różnych platform docelowych, które chcą obsługiwać, i dołączają wszystkie te zestawy do tego samego pakietu (nazywanego "wielowersyjnością"). 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 wielowersyjny jest oczywiście trudniejszy dla jego twórcy do utrzymania.

Uwaga

Aby uzyskać wskazówki dotyczące składników aplikacji a bibliotek wielokrotnego użytku, zobacz dokumentację platformy .NET Standard dotyczącą tego tematu.

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	wszystkie	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 pewne możliwości interfejsu wiersza polecenia NuGet bezpośrednio w łańcuchu narzędzi platformy .NET Core. Podobnie jak w przypadku interfejsu nuget.exe wiersza polecenia interfejs wiersza polecenia dotnet nie wchodzi w interakcje z projektami programu Visual Studio.
Interfejs wiersza polecenia nuget.exe	wszystkie	Tworzenie, zużycie	Narzędzie interfejsu wiersza polecenia dla bibliotek programu .NET Framework i projektów innych niż ZESTAW SDK przeznaczonych dla bibliotek platformy .NET Standard. Udostępnia wszystkie funkcje NuGet, a niektóre polecenia stosowane specjalnie do twórców pakietów, niektóre mają zastosowanie tylko do konsumentów, a inne mają zastosowanie do obu tych elementów. Na przykład twórcy pakietów używają nuget pack polecenia , 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 polecenia 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	Zużycie	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	Zużycie	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 narzędzia NuGet	Visual Studio dla komputerów Mac	Zużycie	Zapewnij łatwy w użyciu interfejs użytkownika do instalowania pakietów i zarządzania nimi w projektach 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 przepływu pracy tworzenia pakietów i przepływu pracy Zużycie pakietu.

Zarządzanie zależnościami

Możliwość łatwego budowania pracy innych jest jedną z najbardziej zaawansowanych 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 po prostu, potrzebujesz tylko siebie z tymi pakietami, 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 ciężko pracuje, aby określić dokładnie, która wersja pakietu B spełnia 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 wykonywania tej usługi przez pakiet NuGet, zobacz Rozwiązywanie zależności.

Śledzenie odwołań 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. Dzięki temu każda kopia projektu będzie niepotrzebnie rozdęty (a tym samym marnować miejsce w repozytoriach kontroli źródła). 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 na poziomie podrzędnym. 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 narzędzie NuGet umożliwia przywrócenie wszystkich pakietów, do których odwołuje się żądanie, zgodnie z opisem w temacie Przywracanie pakietów.

Przy użyciu tylko listy referencyjnej program NuGet może następnie ponownie zainstalować — czyli przywrócić — wszystkie te pakiety z publicznych i/lub prywatnych hostów 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 Pakiety i kontrola źródła).

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" 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 (Menedżer pakietów Console), 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 temacie Przywracanie pakietu).

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 pakietu 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 folderze packages .

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 go w katalogu głównym projektu po zainstalowaniu pierwszego pakietu. Jeśli nie masz tego pliku, poszukaj w pliku projektu bezpośrednio dla <elementu PackageReference> .

Jeśli masz wybór, zalecamy użycie funkcji PackageReference. packages.config jest utrzymywany w starszych celach i nie jest już aktywnie rozwijany.

Napiwek

Różne nuget.exe polecenia interfejsu wiersza polecenia, takie jak nuget install, nie dodają automatycznie pakietu do listy odwołań. Lista jest aktualizowana podczas instalowania pakietu za pomocą programu Visual Studio Menedżer pakietów (interfejs użytkownika lub konsoli) oraz interfejsu dotnet.exe wiersza polecenia.

Co jeszcze robi NuGet?

Do tej pory znasz następujące cechy narzędzia NuGet:

• Pakiet NuGet udostępnia centralne repozytorium nuget.org z obsługą hostingu prywatnego.
• 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 pakietami globalnymi 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 dotyczące struktury pakietów (w tym lokalizacji i symboli debugowania) oraz sposobu ich odwołwania się (w tym zakresów wersji i wersji wstępnych). 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śmiń chwilę, aby przejrzeć spis treści tej dokumentacji i zobaczysz wszystkie te możliwości przedstawione tam wraz z informacjami o wersji pochodzącymi z początków NuGet.

Powiązany film wideo

Więcej filmów NuGet można znaleźć w witrynach Channel 9 i YouTube.

Komentarze, współtworzenie i problemy

Na koniec bardzo mile widziane komentarze i współtworzenie tej dokumentacji — po prostu wybierz polecenia Opinie i edytuj w górnej części dowolnej strony lub odwiedź repozytorium dokumentacji i listę problemów z dokumentami w usłudze 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 witrynie https://github.com/NuGet/home/issues.

Ciesz się swoim środowiskiem NuGet!