Aggiungere pacchetti al progetto .NET
.NET include molte librerie di base che gestiscono tutti gli aspetti, dalla gestione dei file ad HTTP, fino alla compressione dei file. Esiste anche un enorme ecosistema di librerie di terze parti. È possibile usare NuGet, ovvero lo strumento per la gestione dei pacchetti .NET, per installare queste librerie e usarle nell'applicazione.
In .NET e nel suo ecosistema viene usato molto il termine dipendenza. Una dipendenza del pacchetto è una libreria di terze parti. È un frammento di codice riutilizzabile che esegue un'operazione e che è possibile aggiungere all'applicazione. La libreria di terze parti è un elemento da cui l'applicazione dipende per funzionare e da questo deriva il termine dipendenza.
È possibile paragonare la libreria di terze parti a un pacchetto ed è archiviata in un repository. Un pacchetto è costituito da una o più librerie che è possibile aggiungere all'applicazione in modo da trarre vantaggio dalle sue funzionalità.
Ci si concentrerà sulle dipendenze del pacchetto. Un progetto .NET può avere altri tipi di dipendenze, tra cui framework, analizzatori, riferimenti a progetti e dipendenze di progetto condivise, oltre alle dipendenze nel pacchetto.
Determinare se è necessario un pacchetto
Come è possibile stabilire se è necessario un pacchetto per il progetto? Si tratta di una domanda complessa con alcune implicazioni:
- Ottenere codice migliore: si supponga di dover gestire un'attività come la sicurezza, ad esempio, provando a implementare i meccanismi di autenticazione e autorizzazione. Si tratta di un'attività per cui è importante non commettere errori per mantenere protetti i dati interni e quelli dei clienti. Sono disponibili modelli standard e librerie usate da molti sviluppatori. Queste librerie implementano funzionalità che probabilmente saranno sempre necessarie e i problemi vengono corretti man mano che si verificano. È consigliabile usare tali librerie invece di crearne di nuove. Molto probabilmente non si riuscirà a scrivere codice migliore, considerando gli innumerevoli casi limite di cui è necessario tenere conto.
- Risparmio di tempo: probabilmente è possibile creare molti elementi manualmente, ad esempio librerie di utilità o di componenti dell'interfaccia utente, ma ciò richiede tempo. Anche se il risultato è paragonabile a ciò che è già disponibile, non è un buon uso del proprio tempo replicare la scrittura di codice non necessario.
- Manutenzione: tutte le librerie e le app prima o poi richiedono manutenzione. La manutenzione include l'aggiunta di nuove funzionalità e la correzione dei bug. È bene chiedersi se dedicare il proprio tempo o quello del team alla manutenzione di una libreria sia una buona scelta o se sia preferibile delegarne la gestione a un team che si occupa del software open source.
Valutare un pacchetto
Prima di installare una libreria, è consigliabile controllare le dipendenze su cui si basa. Queste dipendenze possono incoraggiarne l'uso oppure rappresentare un deterrente. Di seguito sono riportati alcuni fattori da considerare quando si seleziona una dipendenza per il progetto:
- Dimensioni: il numero di dipendenze può avere un notevole footprint. Se la larghezza di banda è limitata o esistono altre limitazioni hardware, questo fattore potrebbe costituire un problema.
- Gestione licenze: è necessario verificare che la licenza concessa per la libreria consenta l'uso previsto, commerciale, personale o accademico.
- Manutenzione attiva: se il pacchetto si basa su una dipendenza deprecata o che non è stata aggiornata da molto tempo, questo potrebbe costituire un problema.
È possibile ottenere ulteriori informazioni su un pacchetto prima di installarlo visitando https://www.nuget.org/packages/<package name>. Questo URL apre una pagina dettagliata per il pacchetto. Selezionare l'elenco a discesa Dipendenze per visualizzare i pacchetti su cui si basa il progetto per funzionare.
Il numero di dipendenze elencate potrebbe non essere indicativo. Se si scarica un pacchetto, si può finire per ottenere una dipendenza del pacchetto che contiene diverse decine di pacchetti. Perché? Ogni pacchetto include un elenco di dipendenze. Per assicurarsi di poter usare un pacchetto, tutte le dipendenze vengono sottoposte a ricerca per indicizzazione e scaricate quando si esegue il comando dotnet add package <package name>.
Installare un pacchetto
L'installazione di pacchetti può essere eseguita in diversi modi. In Visual Studio e Visual Studio per Mac sono integrate una riga di comando e un'interfaccia utente grafica per uno strumento per la gestione dei pacchetti. È possibile aggiungere manualmente riferimenti al pacchetto al file di progetto oppure installarli tramite uno strumento di interfaccia della riga di comando, come Paket o l'interfaccia della riga di comando di .NET Core.
Per questo modulo, si userà l'interfaccia della riga di comando di .NET Core per installare i pacchetti. È possibile aggiungere un pacchetto al progetto .NET richiamando un comando nel terminale. Un comando di installazione tipico è simile a questo: dotnet add package <name of package>. Quando si esegue il comando add package, lo strumento da riga di comando si connette a un registro globale, recupera il pacchetto e lo archivia nel percorso di una cartella memorizzata nella cache che può essere usato da tutti i progetti.
Dopo l'installazione e la compilazione del progetto, i riferimenti vengono aggiunti alle cartelle di debug o di rilascio. La directory del progetto ha un aspetto simile al seguente:
-| bin/
---| Debug/
------| net3.1
--------| <files included in the dependency>
Trovare un pacchetto
Singoli sviluppatori possono usare il registro globale in NuGet.org per trovare e scaricare i pacchetti necessari per le app. Un'azienda potrebbe aver definito una strategia per stabilire quali pacchetti possono essere usati senza problemi e dove trovarli.
I pacchetti possono trovarsi in molte posizioni diverse. Alcune di queste origini potrebbero essere disponibili pubblicamente, altre potrebbero presentare restrizioni ed essere disponibili solo per i dipendenti di una società specifica. Di seguito sono elencate alcune posizioni in cui possono risiedere i pacchetti:
- Registri: un esempio può essere un registro globale come il registro NuGet.org. È possibile ospitare registri personalizzati che possono essere privati o pubblici. Servizi come GitHub e Azure DevOps rendono disponibili registri privati.
- File: è possibile installare un pacchetto da una cartella locale. L'installazione da un pacchetto è uno scenario comune quando si prova a sviluppare librerie .NET personalizzate e si vuole testare il pacchetto in locale o per qualche motivo non si vuole usare un registro.
Registro NuGet e strumento dotnet
Quando si esegue dotnet add package <name of dependency>, .NET passa a un registro globale denominato registro NuGet.org e cerca il codice da scaricare. Il registro si trova alla pagina https://nuget.org. In questa pagina, se viene visitata usando un browser, è anche possibile cercare i pacchetti. Ogni pacchetto ha un sito Web dedicato a cui è possibile accedere.
In questi siti è possibile ottenere altre informazioni sulla posizione in cui si trova il codice sorgente. È anche possibile trovare informazioni come le metriche sui download e informazioni sulla manutenzione.
Comandi .NET
Finora si è visto come sia possibile installare le dipendenze usando l'interfaccia della riga di comando di .NET Core. Questo strumento offre però molte altre funzionalità.
L'interfaccia della riga di comando di .NET Core include diversi comandi. I comandi consentono di eseguire attività come l'installazione di pacchetti, la creazione di pacchetti e l'inizializzazione di progetti .NET. Non è necessario conoscere tutti i comandi nel dettaglio. Quando si inizia a usare .NET, probabilmente si usa solo un subset dei comandi. Con l'acquisire di maggiore esperienza in .NET, si tenderà a usare sempre più comandi di un'ampia gamma di categorie.
Per ricordare più facilmente gli scopi dei comandi, può essere utile considerarne la categoria:
- Gestione delle dipendenze: i comandi in questa categoria riguardano l'installazione, la rimozione, la pulizia dopo le installazioni dei pacchetti e gli aggiornamenti dei pacchetti.
- Esecuzione di programmi: lo strumento .NET Core può essere utile per gestire flussi nello sviluppo dell'applicazione. Esempi di flussi dell'applicazione sono l'esecuzione di test, la compilazione di codice e l'esecuzione di comandi di migrazione per l'aggiornamento di progetti.
- Creazione e pubblicazione di pacchetti: diversi comandi consentono di eseguire attività quali la creazione di un pacchetto compresso e il push del pacchetto in un registro.
Per visualizzare un elenco dettagliato di tutti i comandi, immettere dotnet --help nel terminale.
Come installare un pacchetto
Usare il comando dotnet add package <dependency name> per installare una dipendenza normale destinata a essere usata come parte dell'applicazione.
Nota
È possibile installare alcuni pacchetti a livello globale. Questi pacchetti non sono destinati a essere importati nel progetto. Per questo motivo, molti pacchetti globali sono strumenti dell'interfaccia della riga di comando o modelli. È anche possibile installare questi strumenti globali da un repository di pacchetti. Installare gli strumenti usando il comando dotnet tool install <name of package>. Installare i modelli usando il comando dotnet new -i <name of package>.
Dopo l'installazione
I pacchetti installati sono elencati nella sezione dependencies del file con estensione csproj. Per visualizzare i pacchetti presenti nella cartella, è possibile immettere dotnet list package.
Project 'DotNetDependencies' has the following package references
[net8.0]:
Top-level Package Requested Resolved
> Humanizer 2.7.9 2.7.9
Questo comando elenca solo i pacchetti di primo livello e non le dipendenze dei pacchetti noti come pacchetti transitivi. Può andare bene per un'analisi rapida. Per ottenere una visualizzazione più approfondita, è possibile elencare tutti i pacchetti transitivi. Quando si esegue questa operazione, il comando list è simile al seguente:
dotnet list package --include-transitive
Includendo i pacchetti transitivi, sarà possibile visualizzare le dipendenze con tutti i pacchetti installati. Se si esegue dotnet list package --include-transitive verrà visualizzato un output simile al seguente:
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
...
Ripristinare le dipendenze
Quando si crea o clona un progetto, le dipendenze incluse non vengono scaricate o installate finché non si compila il progetto. È possibile ripristinare manualmente le dipendenze nonché gli strumenti specifici del progetto indicati nel file di progetto eseguendo il comando dotnet restore. Nella maggior parte dei casi non è necessario usare il comando in modo esplicito. Il ripristino di NuGet viene eseguito in modo implicito, se necessario, quando si eseguono comandi come new, build e run.
Pulizia delle dipendenze
Prima o poi, probabilmente ci si rende conto che un pacchetto non è più necessario o ci si potrebbe rendere conto che il pacchetto installato non è quello effettivamente necessario. ed è possibile che se ne trovi uno più adatto all'attività prevista. Indipendentemente dal motivo, è consigliabile rimuovere le dipendenze non usate per mantenere un certo livello di ordine e pulizia. Inoltre, le dipendenze occupano spazio.
Per rimuovere un pacchetto dal progetto, usare il comando remove, in questo modo: dotnet remove package <name of dependency>. Questo comando rimuove il pacchetto dal file con estensione csproj del progetto.