Non esiste ormai (almeno spero) un Dev che non conosca ed usi quotidianamente NuGet per gestire i riferimenti alle librerie esterne che utilizza nei propri progetti.
Se ci fosse qualcuno appena sceso da Marte che ancora ignorasse l'esistenza di NuGet (peste lo colga) può consultare un mio vecchio articolo sul sito di DomusDotNet che, pur essendo datato, contiene ancora le informazioni di base per capire di cosa si stia parlando.
Come sappiamo, e come viene spiegato nell'articolo, per impostazione di base NuGet scarica i suoi pacchetti nella sottocartella packages che si trova nella cartella della solution. Tale scelta aveva parecchio senso fino ad un po' di tempo fa perché consentiva di avere in un unico posto (la cartella della solution) tutto il codice (personale o di terze parti) necessario per far funzionare il progetto.
Gli eseguibili scaricati via NuGet (tipicamente DLL) vengono infatti referenziati nel progetto direttamente nella cartella in cui sono stati scaricati. Copiare i file di progetto senza portarsi dietro la cartella packages vuol dire quindi prepararsi a fronteggiare una serie di errori di compilazione dati dalla perdita dei riferimenti delle DLL esterne (i famigerati alert gialli nella cartella References).
Da qualche tempo è però disponibile la modalità detta Package Restore che consente di istruire NuGet affinché recuperi in automatico i riferimenti persi scaricando nuovamente i pacchetti mancanti in fase di compilazione.
L'esigenza di avere i pacchetti insieme alla solution è quindi venuta meno ed è possibile modificare il comportamento di NuGet per evitare un'inutile proliferazione di cartelle packages contenenti quasi sempre più o meno gli stessi pacchetti (Entity Framework, jQuery, ecc.).
Una delle modalità possibili – quella che preferisco e che ovviamente adotto – è quella di centralizzare lo scarico dei pacchetti in un'unica cartella che funga da repository univoco per tutti i progetti. Nel mio caso sono solito creare una cartella Packages nella root di Visual Studio (allo stesso livello di Projects tanto per capirsi) ma una qualsiasi altra cartella va parimenti bene.
Si tratta ora di configurare NuGet affinché utilizzi questa cartella per tutti i progetti. Per farlo è sufficiente modificare il file NuGet.config situato nella cartella %APPDATA%\NuGet (nel mio caso C:\Users\Giorgio\AppData\Roaming\NuGet). Per aprire il file la cosa più semplice è digitare %APPDATA%\NuGet\NuGet.config nella barra degli indirizzi del File Explorer.
Il placeholder %APPDATA% viene convertito automaticamente e il file viene aperto direttamente in Visual Studio.
All'interno del file dobbiamo aggiungere sotto configuration/config un nodo Add con key repositorypath e value uguale alla cartella nella quale vogliamo scaricare i pacchetti (nel mio caso C:\Users\Giorgio\Documents\Visual Studio 2013\Packages) con sintassi simile a quella che usiamo per specificare setting personalizzati nel Web.config.
Anche se non è strettamente necessario vi consiglio di aggiungere un nodo con la stesso value anche sotto configuration/packageSources. In questo caso potete scegliere la key a vostra preferenza, io sono solito usare localhost per indicare che trattasi della sorgente locale. Vedremo a breve quale sia lo scopo di questa seconda chiave.
Salviamo il file e siamo pronti per cominciare.
Apriamo Visual Studio, creiamo un nuovo progetto (ad esempio una ASP.NET Web Application con MVC e WebAPI) e vedremo che i pacchetti scaricati da NuGet andranno a finire nel repository che abbiamo specificato nel file NuGet.config.
Il vantaggio di questa soluzione non è solo nel risparmio di spazio su disco (avendo un solo repository globale invece che uno per solution) ma anche nella possibilità di lavorare in mobilità o addirittura off-line con maggiore flessibilità. Quando creiamo un nuovo progetto, Visual Studio si collega infatti automaticamente a nuget.org per scaricare i pacchetti compresi nel template che abbiamo scelto di utilizzare. In mancanza di connessione il download non riesce ed il progetto non è in grado di funzionare. Inoltre i pacchetti sono solitamente abbastanza corposi e scaricarli con una connessione mobile può essere lungo e costoso.
Nel nostro caso è necessario scaricare i pacchetti solo una volta, successivamente NuGet troverà il pacchetto già disponibile nel repository e lo userà senza necessità di ulteriori download.
Lo stesso vantaggio è sfruttabile nei casi di aggiornamento dei pacchetti (cosa sempre necessaria per i nuovi progetti visto che i template incapsulano versioni delle varie librerie che tendono ad essere rapidamente obsolete). In questo caso possiamo sfruttare il Package Source che abbiamo definito nel file NuGet.config (quello che io avevo chiamato localhost).
Aprendo la maschera Manage NuGet Packages troviamo infatti tra le fonti anche il nostro localhost (il nome dipende dal nome che avete assegnato nel file NuGet.config) che ci consentirà di aggiornare il progetto appena creato con gli eventuali pacchetti più aggiornati che avessimo scaricato precedentemente.
Happy coding!