Een inleiding tot NuGet

Een essentieel hulpprogramma voor elk modern ontwikkelplatform is een mechanisme waarmee ontwikkelaars nuttige code kunnen maken, delen en gebruiken. Dergelijke code wordt vaak gebundeld in 'pakketten' die gecompileerde code (als DLL's) bevatten, samen met andere inhoud die nodig is in de projecten die deze pakketten gebruiken.

Voor .NET (inclusief .NET Core) wordt het door Microsoft ondersteunde mechanisme voor het delen van code NuGet, waarmee wordt gedefinieerd hoe pakketten voor .NET worden gemaakt, gehost en verbruikt en de hulpprogramma's voor elk van deze rollen biedt.

Eenvoudig gezegd is een NuGet-pakket één ZIP-bestand met de .nupkg-extensie die gecompileerde code (DLL's) bevat, andere bestanden met betrekking tot die code en een beschrijvend manifest met informatie zoals het versienummer van het pakket. Ontwikkelaars met code om te delen, maken pakketten en publiceren deze op een openbare of privéhost. Pakketgebruikers verkrijgen deze pakketten van geschikte hosts, voegen ze toe aan hun projecten en roepen vervolgens de functionaliteit van een pakket aan in hun projectcode. NuGet zelf verwerkt vervolgens alle tussenliggende gegevens.

Omdat NuGet ondersteuning biedt voor privéhosts naast de openbare nuget.org host, kunt u NuGet-pakketten gebruiken om code te delen die exclusief is voor een organisatie of een werkgroep. U kunt NuGet-pakketten ook gebruiken als een handige manier om uw eigen code te factoren voor gebruik in niets anders dan uw eigen projecten. Kortom, een NuGet-pakket is een deelbare code-eenheid, maar vereist geen enkele specifieke manier van delen.

De stroom van pakketten tussen makers, hosts en consumenten

In zijn rol als openbare host onderhoudt NuGet zelf de centrale opslagplaats van meer dan 100.000 unieke pakketten op nuget.org. Deze pakketten worden elke dag door miljoenen .NET/.NET Core-ontwikkelaars gebruikt. Met NuGet kunt u ook privé pakketten hosten in de cloud (zoals in Azure DevOps), in een particulier netwerk of zelfs op uw lokale bestandssysteem. Hierdoor zijn deze pakketten alleen beschikbaar voor ontwikkelaars die toegang hebben tot de host, zodat u pakketten beschikbaar kunt maken voor een specifieke groep consumenten. De opties worden uitgelegd in Uw eigen NuGet-feeds hosten. Via configuratieopties kunt u ook precies bepalen welke hosts toegankelijk zijn voor elke computer, waardoor pakketten worden verkregen uit specifieke bronnen in plaats van een openbare opslagplaats zoals nuget.org.

Hoe dan ook, een host fungeert als het punt van verbinding tussen pakket makers en pakket consumenten. Makers bouwen nuttige NuGet-pakketten en publiceren ze naar een host. Consumenten zoeken vervolgens naar nuttige en compatibele pakketten op toegankelijke hosts, downloaden en opnemen van die pakketten in hun projecten. Zodra deze in een project is geïnstalleerd, zijn de API's van de pakketten beschikbaar voor de rest van de projectcode.

Pakketdoelcompatibiliteit

Een 'compatibel' pakket betekent dat het assembly's bevat die zijn gebouwd voor ten minste één doel .NET Framework dat compatibel is met het doelframework van het verbruikende project. Ontwikkelaars kunnen pakketten maken die specifiek zijn voor één framework, net als met UWP-besturingselementen, of ze kunnen een breder scala aan doelen ondersteunen. Om de compatibiliteit van een pakket te maximaliseren, richten ontwikkelaars zich op .NET Standard-, die alle .NET- en .NET Core-projecten kunnen gebruiken. Dit is de meest efficiënte manier voor zowel makers als gebruikers, omdat een enkel pakket (meestal met een enkele assembly) werkt voor alle projecten die het gebruiken.

Pakketontwikkelaars die API's buiten .NET Standard nodig hebben, maken daarentegen afzonderlijke assembly's voor de verschillende doelframeworks die ze willen ondersteunen en bevatten al deze assembly's in hetzelfde pakket (dit wordt 'multi-targeting' genoemd). Wanneer een consument een dergelijk pakket installeert, extraheert NuGet alleen de assembly's die nodig zijn voor het project. Dit minimaliseert de footprint van het pakket in de uiteindelijke applicatie en/of assemblies die door dat project worden geproduceerd. Een pakket met meerdere targeting is natuurlijk moeilijker te onderhouden voor de maker.

NuGet-hulpprogramma's

Naast hostingondersteuning biedt NuGet ook diverse hulpprogramma's die door zowel makers als consumenten worden gebruikt. Zie NuGet-clienthulpprogramma's installeren voor het verkrijgen van specifieke hulpprogramma's.

Zoals u ziet, zijn de NuGet-hulpprogramma's waarmee u werkt sterk afhankelijk van of u pakketten maakt, verbruikt of publiceert, en het platform waarop u werkt. Pakketmakers zijn doorgaans ook consumenten, omdat ze bouwen op functionaliteit die aanwezig is in andere NuGet-pakketten. En die pakketten kunnen natuurlijk op hun beurt afhankelijk zijn van nog anderen.

Voor meer informatie kunt u beginnen met de artikelen over de werkstroom voor het maken van pakketten en over de werkstroom voor pakketverbruik.

Afhankelijkheden beheren

De mogelijkheid om eenvoudig voort te bouwen op het werk van anderen is een van de krachtigste functies van een pakketbeheersysteem. Daarom beheert veel van wat NuGet doet die afhankelijkheidsstructuur of grafiek namens een project. Gewoon gezegd, u hoeft zich alleen zorgen te maken over die pakketten die u rechtstreeks in een project gebruikt. Als een van deze pakketten zelf andere pakketten verbruikt (die op zijn beurt weer andere pakketten kunnen gebruiken), zorgt NuGet voor al die afhankelijkheden op down-level.

In de volgende afbeelding ziet u een project dat afhankelijk is van vijf pakketten, die op zijn beurt afhankelijk zijn van een aantal andere pakketten.

U ziet dat sommige pakketten meerdere keren worden weergegeven in de afhankelijkheidsgrafiek. Er zijn bijvoorbeeld drie verschillende consumenten van pakket B en elke consument kan ook een andere versie voor dat pakket opgeven (niet weergegeven). Dit is gebruikelijk, met name voor veelgebruikte pakketten. NuGet doet gelukkig al het harde werk om te bepalen welke versie van pakket B voldoet aan alle consumenten. NuGet doet vervolgens hetzelfde voor alle andere pakketten, ongeacht hoe diep de afhankelijkheidsgrafiek is.

Zie Afhankelijkheidsoplossingvoor meer informatie over hoe NuGet deze service uitvoert.

Verwijzingen bijhouden en pakketten terugzetten

Omdat projecten eenvoudig kunnen schakelen tussen ontwikkelaarscomputers, opslagplaatsen voor broncodebeheer, buildservers enzovoort, is het zeer onpraktisch om de binaire assembly's van NuGet-pakketten rechtstreeks gebonden te houden aan een project. Als u dit doet, wordt elke kopie van het project onnodig opgeblazen, wat ruimteverspilling in opslagplaatsen voor broncodebeheer tot gevolg heeft. Het zou ook erg moeilijk maken om binaire pakketbestanden bij te werken naar nieuwere versies, omdat updates moeten worden toegepast op alle kopieën van het project.

NuGet onderhoudt in plaats daarvan een eenvoudige referentielijst van de pakketten waarvan een project afhankelijk is, inclusief zowel afhankelijkheden op het hoogste niveau als afhankelijkheden op een lager niveau. Dat wil gezegd, wanneer u een pakket van een host in een project installeert, registreert NuGet de pakket-id en het versienummer in de referentielijst. (Als u een pakket verwijdert, wordt het natuurlijk uit de lijst verwijderd.) NuGet biedt vervolgens een methode voor het herstellen van alle pakketten waarnaar wordt verwezen op verzoek, zoals beschreven in pakketherstel.

Met alleen de referentielijst kan NuGet op elk gewenst moment opnieuw installeren( dat wil gezegd herstellen) al deze pakketten van openbare en/of privéhosts op een later tijdstip. Wanneer u een project doorvoert in broncodebeheer of op een andere manier deelt, neemt u alleen de referentielijst op en sluit u binaire pakketbestanden uit (zie Pakketten en broncodebeheer.)

De computer die een project ontvangt, zoals een buildserver die een kopie van het project verkrijgt als onderdeel van een geautomatiseerd implementatiesysteem, vraagt NuGet om afhankelijkheden te herstellen wanneer ze nodig zijn. Bouwsystemen zoals Azure DevOps bieden nuget-herstelstappen voor dit exacte doel. Op dezelfde manier kunnen ontwikkelaars, wanneer ontwikkelaars een kopie van een project verkrijgen (zoals bij het klonen van een opslagplaats), opdracht zoals nuget restore (NuGet CLI), dotnet restore (dotnet CLI) of Install-Package (Package Manager Console) aanroepen om alle benodigde pakketten te verkrijgen. Visual Studio herstelt voor zijn deel automatisch pakketten bij het bouwen van een project (mits automatisch herstellen is ingeschakeld, zoals beschreven in pakketherstel).

De primaire rol van NuGet voor ontwikkelaars is het bijhouden van de referentielijst namens uw project en het bieden van de middelen om de verwijzingen efficiënt te herstellen (en bij te werken). Deze lijst wordt onderhouden in een van de twee indelingen voor pakketbeheer, zoals ze worden genoemd:

• PackageReference (of 'pakketverwijzingen in projectbestanden') | (NuGet 4.0+) Onderhoudt een lijst met afhankelijkheden op het hoogste niveau van een project rechtstreeks in het projectbestand, zodat er geen afzonderlijk bestand nodig is. Een gekoppeld bestand, obj/project.assets.json, wordt dynamisch gegenereerd om de algehele afhankelijkheidsgrafiek te beheren van de pakketten die een project gebruikt, samen met alle afhankelijkheden op down-level. PackageReference wordt altijd gebruikt door .NET Core-projecten.

• packages.config: (NuGet 1.0+) Een XML-bestand dat een platte lijst met alle afhankelijkheden in het project onderhoudt, inclusief de afhankelijkheden van andere geïnstalleerde pakketten. Geïnstalleerde of herstelde pakketten worden opgeslagen in een packages map.

Welke pakketbeheerindeling in een bepaald project wordt gebruikt, is afhankelijk van het projecttype en de beschikbare versie van NuGet (en/of Visual Studio). Als u wilt controleren welke indeling wordt gebruikt, zoekt u naar packages.config in de hoofdmap van het project nadat u uw eerste pakket hebt geïnstalleerd. Als u dat bestand niet hebt, bekijk dan rechtstreeks in het projectbestand het element <PackageReference>.

Als u een keuze hebt, raden we u aan PackageReference te gebruiken. packages.config wordt onderhouden voor verouderde doeleinden en wordt niet langer actief ontwikkeld.

Wat doet NuGet nog meer?

Tot nu toe hebt u de volgende kenmerken van NuGet geleerd:

• NuGet biedt de centrale nuget.org opslagplaats met ondersteuning voor privéhosting.
• NuGet biedt de hulpprogramma's die ontwikkelaars nodig hebben voor het maken, publiceren en gebruiken van pakketten.
• Het belangrijkste is dat NuGet een referentielijst onderhoudt met pakketten die in een project worden gebruikt en de mogelijkheid om deze pakketten uit die lijst te herstellen en bij te werken.

Om deze processen efficiënt te laten werken, voert NuGet enkele optimalisaties achter de schermen uit. Met name beheert NuGet een pakketcache en een globale pakketmap voor snelkoppelingsinstallatie en herinstallatie. De cache vermijdt het downloaden van een pakket dat al op de computer is geïnstalleerd. Met de globale pakketmap kunnen meerdere projecten hetzelfde geïnstalleerde pakket delen, waardoor de totale footprint van NuGet op de computer wordt verminderd. De map met cache- en globale pakketten is ook erg handig wanneer u regelmatig een groter aantal pakketten herstelt, zoals op een buildserver. Zie Algemene pakketten en cachemappen beherenvoor meer informatie over deze mechanismen.

Binnen een afzonderlijk project beheert NuGet de algehele afhankelijkheidsgrafiek, waaronder het omzetten van meerdere verwijzingen naar verschillende versies van hetzelfde pakket. Het is vrij gebruikelijk dat een project afhankelijk is van een of meer pakketten die zelf dezelfde afhankelijkheden hebben. Sommige van de nuttigste hulpprogrammapakketten op nuget.org worden gebruikt door vele andere pakketten. In de volledige afhankelijkheidsgrafiek zou u dan eenvoudig tien verschillende verwijzingen naar verschillende versies van hetzelfde pakket kunnen hebben. Om te voorkomen dat meerdere versies van dat pakket in de toepassing zelf worden geplaatst, sorteert NuGet welke enkele versie door alle consumenten kan worden gebruikt. (Voor meer informatie, zie Afhankelijkheidsoplossing.)

Bovendien houdt NuGet alle specificaties bij die betrekking hebben op de structuur van pakketten (inclusief lokalisatie en foutopsporingssymbolen) en hoe ze worden waarnaar wordt verwezen (inclusief versiebereiken en pre-releaseversies.) NuGet biedt ook verschillende API's om programmatisch met de services te werken en biedt ondersteuning voor ontwikkelaars die Visual Studio-extensies en projectsjablonen schrijven.

Neem even de tijd om door de inhoudsopgave voor deze documentatie te bladeren en u ziet al deze mogelijkheden die daar worden weergegeven, samen met releaseopmerkingen die teruggaan naar het begin van NuGet.

Gerelateerde video

Vind NuGet-video's op Channel 9 en YouTube-.

Opmerkingen, bijdragen en problemen

Ten slotte zijn we zeer verheugd over opmerkingen en bijdragen aan deze documentatie. Selecteer de Feedback en Opdrachten bewerken boven aan een willekeurige pagina of ga naar de docs-opslagplaats en lijst met problemen met documenten op GitHub.

We verwelkomen ook bijdragen aan NuGet zelf via de verschillende GitHub-opslagplaatsen; NuGet-problemen zijn te vinden op https://github.com/NuGet/home/issues.

Geniet van uw NuGet-ervaring!