Update 17/02: alla luce dei commenti di Ugo e Marco ho cercato di rendere più chiaro il fatto che la vecchia modalità di Package Restore va abbandonata in favore della nuova. Spero di aver reso il concetto più chiaro.
Capita spesso che, quando si comincia ad utilizzare un prodotto nelle prime fasi del suo sviluppo, ci si abitui ad un certo modo di risolvere i problemi e si perdano di vista successivi miglioramenti.
È quello che mi è capitato con la funzione Package Restore di NuGet che è stata aggiunta per risolvere un problema molto sentito in ambito source control: evitare di dover salvare sul repository (nel mio caso Team Foundation Server prima e Visual Studio Online successivamente) i package necessari al funzionamento del progetto.
Per impostazione predefinita NuGet scarica tali pacchetti nella cartella della solution e referenzia quindi nel progetto gli eseguibili (DLL) che si trovano nelle cartelle scaricate. Questo richiede (o meglio richiedeva) la necessità di caricare sul server TFS o VSO anche tutta la cartella packages quasi sempre molto onerosa in termini di spazio essendo tra l'altro i pacchetti spesso disponibili per piattaforme diverse (.NET 4 o 4.5, Windows Phone, ecc.) e comunque soggetti ad aggiornamento nel corso della vita del progetto.
Per risolvere questa problematica già da diverso tempo era disponibile su NuGet una modalità di Package Restore che sfruttava l'integrazione in MSBuild (con alcune limitazioni ad esempio sui progetti Web Site). Tale modalità, attivabile tuttora selezionando la voce Enable NuGet Package Restore dal menu contestuale della solution nel Solution Explorer, è da ritenersi obsoleta e da evitare se non volete causare sofferenza a migliaia di innocenti gattini.
A partire dalla versione 2.7 di NuGet è stata infatti aggiunta una nuova modalità automatica che, per tornare alla premessa di questo post, fino a qualche giorno fa ignoravo e che rende l'intera procedura assai più semplice e trasparente.
Partiamo da un nuovo progetto ASP.NET Web Application.
Specifichiamo il template Web API giusto per avere un po' di pacchetti scaricati da NuGet.
Se esaminiamo il file packages.config vediamo che effettivamente il nostro progetto utilizza una serie di pacchetti NuGet.
I pacchetti come sappiamo sono stati scaricati nella cartella packages a livello di solution oppure in una cartella alternativa se, come abbiamo visto in questo post, abbiamo modificato il repositorypath nel file NuGet.config (nel mio caso in C:\Users\Giorgio\Documents\Visual Studio 2013\Packages).
Per verificare il funzionamento del Package Restore rinominiamo (o cancelliamo) la cartella, ad esempio in _Packages, in modo che non sia più riconosciuta da NuGet.
Torniamo ora sul Visual Studio e selezioniamo la voce Manage NuGet Packages… dal menu contestuale delle References del progetto.
NuGet si accorge della mancanza dei pacchetti e ci propone la possibilità di effettuare un restore manuale per ripristinare il funzionamento del progetto.
Invece di usare questa modalità, chiudiamo semplicemente la finestra e lanciamo una compilazione della solution. Anche in questo caso NuGet si accorge della mancanza dei pacchetti e provvede automaticamente a scaricarli.
La finestra di Output ci conferma l'operazione di ripristino dei pacchetti mancanti e il progetto viene compilato correttamente.
Entrambe le modalità (quella manuale via Manage NuGet Packages… e quella automatica in fase di build) possono essere disabilitate a propria scelta (tenendo conto che per impostazione predefinita sono abilitate).
Nelle opzioni di Visual Studio selezioniamo NuGet Package Manager > General e disabilitiamo l'opzione Automatically check for missing packages during build in Visual Studio (se vogliamo mantenere la possibilità di ripristinare i pacchetti mancanti con la procedura manuale) o l'opzione Allow NuGet to download missing packages (se vogliamo completamente impedire la possibilità di ripristino).
Happy coding!
posted @ martedì 11 febbraio 2014 16:48