Introduzione a NuGet

Uno strumento essenziale per qualsiasi piattaforma di sviluppo moderna è un meccanismo attraverso il quale gli sviluppatori possono creare, condividere e usare codice utile. Spesso tale codice viene in bundle in "pacchetti" che contengono codice compilato (come DLL) insieme ad altri contenuti necessari nei progetti che usano questi pacchetti.

Per .NET (incluso .NET Core), il meccanismo supportato da Microsoft per la condivisione del codice è NuGet, che definisce come vengono creati, ospitati e usati i pacchetti per .NET e fornisce gli strumenti per ognuno di questi ruoli.

In poche parole, un pacchetto NuGet è un singolo file ZIP con l'estensione .nupkg che contiene codice compilato (DLL), altri file correlati a tale codice e un manifesto descrittivo che include informazioni come il numero di versione del pacchetto. Gli sviluppatori che desiderano condividere il codice creano pacchetti e li pubblicano su un host pubblico o privato. Gli utenti dei pacchetti ottengono tali pacchetti da host adatti, li aggiungono ai loro progetti e chiamano la loro funzionalità nel codice del progetto. NuGet gestisce quindi tutti i dettagli intermedi.

Poiché NuGet supporta host privati insieme all'host pubblico nuget.org, è possibile usare i pacchetti NuGet per condividere il codice esclusivo di un'organizzazione o di un gruppo di lavoro. È anche possibile usare i pacchetti NuGet come modo pratico per tenere conto del proprio codice da usare in progetti personalizzati. In breve, un pacchetto NuGet è un'unità di codice condivisibile, ma non richiede né implica alcun particolare mezzo di condivisione.

Flusso di pacchetti tra creatori, host e consumer

Nel ruolo di host pubblico, NuGet gestisce il repository centrale di oltre 100.000 pacchetti univoci in nuget.org. Questi pacchetti vengono usati da milioni di sviluppatori .NET/.NET Core ogni giorno. NuGet consente anche di ospitare i pacchetti privatamente nel cloud (ad esempio in Azure DevOps), in una rete privata o anche solo nel file system locale. In questo modo, questi pacchetti sono disponibili solo per gli sviluppatori che hanno accesso all'host, offrendo la possibilità di rendere disponibili pacchetti a un gruppo specifico di consumer. Le opzioni sono illustrate in ospitare i propri feed NuGet. Tramite le opzioni di configurazione, è anche possibile controllare esattamente gli host a cui è possibile accedere da qualsiasi computer, assicurando in tal modo che i pacchetti vengano ottenuti da origini specifiche anziché da un repository pubblico come nuget.org.

Indipendentemente dalla sua natura, un host funge da punto di connessione tra i creatori di pacchetti e il pacchetto consumer. Gli autori creano utili pacchetti NuGet e li pubblicano in un host. I consumer cercano quindi pacchetti utili e compatibili su host accessibili, scaricando e includendo tali pacchetti nei progetti. Dopo l'installazione in un progetto, le API dei pacchetti sono disponibili per il resto del codice del progetto.

Compatibilità del pacchetto di destinazione

Un pacchetto "compatibile" significa che contiene assembly compilati per almeno un framework .NET di destinazione compatibile con il framework di destinazione del progetto che usa. Gli sviluppatori possono creare pacchetti specifici di un framework, come con i controlli UWP, oppure supportano una gamma più ampia di destinazioni. Per ottimizzare la compatibilità di un pacchetto, gli sviluppatori hanno come destinazione .NET Standard, che tutti i progetti .NET e .NET Core possono usare. Questo è il mezzo più efficiente sia per i creatori che per i consumatori, in quanto un singolo pacchetto (in genere contenente un singolo assembly) funziona per tutti i progetti di utilizzo.

Gli sviluppatori di pacchetti che richiedono API esterne a .NET Standard, d'altra parte, creano assembly separati per i diversi framework di destinazione che vogliono supportare e includere tutti gli assembly nello stesso pacchetto (denominato "multitargeting"). Quando un consumer installa tale pacchetto, NuGet estrae solo gli assembly necessari per il progetto. Ciò riduce al minimo il footprint del pacchetto nell'applicazione finale e/o negli assembly prodotti da tale progetto. Un pacchetto multitargeting è, naturalmente, più difficile da mantenere per il suo creatore.

Nota

Per indicazioni sui componenti dell'app e sulle librerie riutilizzabili, vedere la documentazione di .NET Standard sull'argomento.

Strumenti NuGet

Oltre al supporto per l'hosting, NuGet offre anche un'ampia gamma di strumenti usati sia dai creatori che dai consumer. Per informazioni su come ottenere strumenti specifici, vedere Installazione di strumenti client NuGet.

Strumento	Piattaforme	Scenari applicabili	Descrizione
dell'interfaccia della riga di comando dotnet	Tutto	Creazione, consumo	Strumento dell'interfaccia della riga di comando per le librerie .NET Core e .NET Standard e per i progetti in stile SDK destinati a .NET Framework (vedere attributo SDK). Fornisce alcune funzionalità dell'interfaccia della riga di comando di NuGet direttamente all'interno della catena di strumenti .NET Core. Come per l'interfaccia della riga di comando di nuget.exe, l'interfaccia della riga di comando dotnet non interagisce con i progetti di Visual Studio.
nuget.exe CLI	Tutto	Creazione, consumo	Strumento dell'interfaccia della riga di comando per librerie .NET Framework e progetti non in stile SDK destinati alle librerie .NET Standard. Fornisce tutte le funzionalità NuGet, con alcuni comandi che si applicano in modo specifico agli autori di pacchetti, alcuni si applicano solo ai consumer e altri si applicano a entrambi. Ad esempio, gli autori di pacchetti usano il comando nuget pack per creare un pacchetto da vari assembly e file correlati, i consumer di pacchetti usano nuget install per includere pacchetti in una cartella del progetto e tutti usano nuget config per impostare le variabili di configurazione NuGet. Come strumento indipendente dalla piattaforma, l'interfaccia della riga di comando di NuGet non interagisce con i progetti di Visual Studio.
Console di Gestione Pacchetti	Visual Studio in Windows	Consumo	Fornisce comandi di PowerShell per l'installazione e la gestione dei pacchetti nei progetti di Visual Studio.
UI del gestore pacchetti	Visual Studio in Windows	Consumo	Fornisce un'interfaccia utente facile da usare per l'installazione e la gestione dei pacchetti nei progetti di Visual Studio.
Gestire l'interfaccia utente di NuGet	Visual Studio per Mac	Consumo	Fornire un'interfaccia utente facile da usare per l'installazione e la gestione dei pacchetti nei progetti Visual Studio per Mac.
msbuild	Windows	Creazione, consumo	Consente di creare pacchetti e ripristinare pacchetti usati in un progetto direttamente tramite la catena di strumenti MSBuild.

Come si può notare, gli strumenti NuGet usati dipendono notevolmente dalla creazione, dall'utilizzo o dalla pubblicazione di pacchetti e dalla piattaforma in cui si lavora. Gli autori di pacchetti sono in genere anche consumatori, poiché si basano sulle funzionalità esistenti in altri pacchetti NuGet. E questi pacchetti, naturalmente, possono dipendere a loro volta da altri.

Per ulteriori informazioni, iniziare con l'articolo sul flusso di lavoro di creazione di pacchetti e l'articolo sul flusso di lavoro relativo all'utilizzo dei pacchetti .

Gestione delle dipendenze

La possibilità di creare facilmente il lavoro di altri utenti è una delle funzionalità più potenti di un sistema di gestione dei pacchetti. Di conseguenza, gran parte delle operazioni eseguite da NuGet è la gestione dell'albero delle dipendenze o del "grafo" per conto di un progetto. Detto semplicemente, è necessario preoccuparsi solo di questi pacchetti che si usano direttamente in un progetto. Se uno di questi pacchetti utilizza altri pacchetti (che a sua volta possono usare ancora altri pacchetti), NuGet si occupa di tutte le dipendenze di livello inferiore.

L'immagine seguente mostra un progetto che dipende da cinque pacchetti, che a sua volta dipendono da un certo numero di altri.

Si noti che alcuni pacchetti vengono visualizzati più volte nel grafico delle dipendenze. Ad esempio, esistono tre consumer diversi del pacchetto B e ogni consumer può anche specificare una versione diversa per tale pacchetto (non visualizzata). Si tratta di un evento comune, soprattutto per i pacchetti ampiamente usati. NuGet esegue fortunatamente tutto il duro lavoro per determinare esattamente quale versione del pacchetto B soddisfa tutti i consumer. NuGet esegue quindi la stessa operazione per tutti gli altri pacchetti, indipendentemente dalla profondità del grafico delle dipendenze.

Per ulteriori dettagli su come NuGet esegue questo servizio, consultare Risoluzione delle dipendenze.

Rilevamento dei riferimenti e ripristino dei pacchetti

Poiché i progetti possono spostarsi facilmente tra computer sviluppatori, repository di controllo del codice sorgente, server di compilazione e così via, è estremamente poco pratico mantenere gli assembly binari dei pacchetti NuGet direttamente associati a un progetto. In questo modo, ogni copia del progetto risulterebbe inutilmente gonfia (e quindi sprecare spazio nei repository di controllo del codice sorgente). Sarebbe anche molto difficile aggiornare i file binari del pacchetto alle versioni più recenti, perché gli aggiornamenti devono essere applicati in tutte le copie del progetto.

NuGet mantiene invece un semplice elenco di riferimenti dei pacchetti da cui dipende un progetto, incluse le dipendenze di primo livello e di livello inferiore. Ovvero, ogni volta che si installa un pacchetto da un host in un progetto, NuGet registra l'identificatore del pacchetto e il numero di versione nell'elenco di riferimenti. La disinstallazione di un pacchetto, naturalmente, la rimuove dall'elenco. NuGet offre quindi un modo per ripristinare tutti i pacchetti a cui si fa riferimento su richiesta, come descritto in ripristino del pacchetto .

Con solo l'elenco di riferimenti, NuGet può quindi reinstallare, ovvero ripristinare, tutti questi pacchetti da host pubblici e/o privati in un secondo momento. Quando si esegue il commit di un progetto nel controllo del codice sorgente o lo si condivide in altro modo, è possibile includere solo l'elenco di riferimenti ed escludere eventuali file binari del pacchetto (vedere pacchetti e controllo del codice sorgente.

Il computer che riceve un progetto, ad esempio un server di compilazione che ottiene una copia del progetto come parte di un sistema di distribuzione automatizzata, chiede semplicemente a NuGet di ripristinare le dipendenze ogni volta che sono necessarie. I sistemi di compilazione come Azure DevOps forniscono i passaggi di "ripristino NuGet" per questo scopo esatto. Analogamente, quando gli sviluppatori ottengono una copia di un progetto (come durante la clonazione di un repository), possono richiamare comandi come nuget restore (interfaccia della riga di comando NuGet), dotnet restore (interfaccia della riga di comando dotnet) o Install-Package (console di Gestione pacchetti) per ottenere tutti i pacchetti necessari. Visual Studio, per la sua parte, ripristina automaticamente i pacchetti durante la compilazione di un progetto (a condizione che il ripristino automatico sia abilitato, come descritto in Ripristino pacchetti).

Chiaramente, il ruolo principale di NuGet in cui gli sviluppatori sono interessati è mantenere tale elenco di riferimenti per conto del progetto e fornire i mezzi per ripristinare (e aggiornare) in modo efficiente tali pacchetti a cui si fa riferimento. Questo elenco viene mantenuto in uno dei due formati di gestione dei pacchetti , come viene chiamato:

• PackageReference (o "riferimenti ai pacchetti nei file di progetto") | (NuGet 4.0+) Mantiene un elenco delle dipendenze di primo livello di un progetto direttamente all'interno del file di progetto, quindi non è necessario alcun file separato. Un file associato, obj/project.assets.json, viene generato dinamicamente per gestire il grafico complessivo delle dipendenze dei pacchetti usati da un progetto insieme a tutte le dipendenze di livello inferiore. PackageReference viene sempre usato dai progetti .NET Core.

• packages.config: (NuGet 1.0+) Un file XML che gestisce un elenco flat di tutte le dipendenze nel progetto, incluse le dipendenze di altri pacchetti installati. I pacchetti installati o ripristinati vengono archiviati in una cartella packages.

Il formato di gestione dei pacchetti usato in qualsiasi progetto dipende dal tipo di progetto e dalla versione disponibile di NuGet (e/o Visual Studio). Per controllare il formato in uso, è sufficiente cercare packages.config nella radice del progetto dopo aver installato il primo pacchetto. Se non si dispone di tale file, cercare direttamente nel file di progetto un <elemento PackageReference>.

Quando si ha una scelta, è consigliabile usare PackageReference. packages.config viene mantenuto a scopo legacy e non è più in fase di sviluppo attivo.

Consiglio

Vari comandi dell'interfaccia della riga di comando di nuget.exe, ad esempio nuget install, non aggiungono automaticamente il pacchetto all'elenco di riferimenti. L'elenco viene aggiornato quando si installa un pacchetto con Gestione pacchetti di Visual Studio (interfaccia utente o console) e con la CLI di dotnet.exe.

Che cos'altro fa NuGet?

Finora sono state apprese le caratteristiche seguenti di NuGet:

• NuGet fornisce il repository nuget.org centrale con supporto per l'hosting privato.
• NuGet offre agli sviluppatori strumenti necessari per la creazione, la pubblicazione e l'utilizzo di pacchetti.
• In particolare, NuGet gestisce un elenco di riferimenti di pacchetti usati in un progetto e la possibilità di ripristinare e aggiornare tali pacchetti da tale elenco.

Per fare in modo che questi processi funzionino in modo efficiente, NuGet esegue alcune ottimizzazioni in background. In particolare, NuGet gestisce una cache dei pacchetti e una cartella di pacchetti globale per semplificare l'installazione e la reinstallazione. La cache evita di scaricare un pacchetto già installato nel computer. La cartella dei pacchetti globali consente a più progetti di condividere lo stesso pacchetto installato, riducendo così il footprint complessivo di NuGet nel computer. Anche la cache e la cartella dei pacchetti globali sono molto utili quando si ripristina spesso un numero maggiore di pacchetti, come in un server di compilazione. Per altri dettagli su questi meccanismi, vedere Gestione dei pacchetti globali e delle cartelle della cache.

All'interno di un singolo progetto, NuGet gestisce il grafico complessivo delle dipendenze, che include anche la risoluzione di più riferimenti a versioni diverse dello stesso pacchetto. È piuttosto comune che un progetto assuma una dipendenza da uno o più pacchetti con le stesse dipendenze. Alcuni dei pacchetti di utilità più utili su nuget.org vengono usati da molti altri pacchetti. Nell'intero grafico delle dipendenze, è quindi possibile avere facilmente dieci riferimenti diversi a versioni diverse dello stesso pacchetto. Per evitare di portare più versioni del pacchetto nell'applicazione stessa, NuGet ordina quale singola versione può essere usata da tutti i consumer. Per ulteriori informazioni, vedere Risoluzione delle dipendenze.

Oltre a ciò, NuGet gestisce tutte le specifiche relative alla struttura dei pacchetti (inclusi di localizzazione e simboli di debug) e il modo in cui vengono a cui viene fatto riferimento (inclusi gli intervalli di versioni e versioni non definitive.) NuGet fornisce anche varie API per lavorare con i servizi a livello di codice e fornisce supporto per gli sviluppatori che scrivono estensioni e modelli di progetto di Visual Studio.

Prenditi un momento per sfogliare il sommario di questa documentazione, e vedrai tutte queste funzionalità rappresentate, insieme alle note sulla versione che risalgono agli inizi di NuGet.

Video correlato

Trova video NuGet su Channel 9 e YouTube.

Commenti, contributi e problemi

Infine, i commenti e i contributi per questa documentazione sono molto graditi: è sufficiente selezionare i comandi commenti e suggerimenti e Modifica nella parte superiore di qualsiasi pagina oppure visitare il repository docs e elenco dei problemi di documentazione su GitHub.

Sono inoltre disponibili contributi a NuGet tramite i relativi vari repository GitHub; I problemi di NuGet sono disponibili in https://github.com/NuGet/home/issues.

Goditi la tua esperienza NuGet!