5

Feb

NuGet e source control: la nuova funzionalità Package Restore

Non ho mai dedicato un post a NuGet, ma se siete sviluppatori .NET credo conosciate già questa preziosa estensione di Visual Studio: si tratta di un package manager che vi permette di aggiungere librerie esterne al vostro progetto in maniera semplice e veloce. NuGet sta guadagnando una popolarità sempre più crecente anche tra gi sviluppatori Windows Phone, tanto che nei tool di sviluppo per Mango NuGet è stato incluso di default (mentre, teoricamente, NuGet non sarebbe disponibile perchè la versione Express di Visual Studio non supporta le estensioni).

In questo post vi voglio parlare di una funzionalità che è stata aggiunta nella versione 1.6 di NuGet, rilasciata recentemente, e che risulterà utilissima per chi ospita i propri progetti su sistemi di source control come TFS, SVN o Mercurial.

Tipicamente, quello che si fa quando si carica un progetto su un sistema di source control è includere non solo il codice sorgente (ovviamente), ma anche tutte le librerie esterne, in modo che chi scarica il progetto trovi tutte le dipendenze già soddisfatte e possa compilare una build senza problemi.

In alcuni casi, quando si usa NuGet, caricare l’intero contenuto della cartella packages (la cartella di default in cui vengono scaricate le librerie) può essere oneroso: questo perchè NuGet scarica sempre l’intera libreria in tutte le versioni disponibili, per poi aggiungere come reference al progetto solo quella corretta.

Prendete ad esempio la celebre libreria MVVM Light di Laurent Bugnion: se la installate in un progetto e andate a vedere i file scaricati nella cartella packages, vi accorgerete che ci sarà una cartella per ognuna delle tecnologie supportate da MVVM Light: .NET 3.5, .NET 4, Silverlight 3, Silverlight 4, Silverlight 5, Windows Phone 7.0 e Windows Phone 7.1.

E’ facile perciò che la cartella packages arrivi ad occupare una dimensione notevole, andando ad “appesantire” le operazioni di download del progetto dal sistema di source control che stiamo utilizzando.

NuGet 1.6 ha introdotto una nuova feature, chiamata Package Restore, che vi permette di risolvere brillantemente questo problema: in pratica, quello che andrete a caricare su source control è l’eseguibile di NuGet assieme ad un file di MsBuild. Grazie a questi file, al primo rebuild della soluzione verranno scaricate in automatico tutte le dipendenze necessarie nel caso non siano già presenti sul vostro disco.

Come funziona? Come spiegato in questo documento ufficiale ora è disponibile una nuova opzione nel menu contestuale di una soluzione, chiamata Enable NuGet Package Restore, che in automatico aggiunge la cartella .nuget (con i file di cui vi parlavo prima) e modifica tutti i progetti in modo che venga eseguito il task di MsBuild in fase di compilazione.

enable-package-restore

Una volta fatta questa modifica, potete eliminare la cartella packages dal vostro sistema di source control: l’importante è che vi ricordiate di fare commit della cartella .nuget, nonchè dei file di progetto (quelli con estensione .csproj o .vbproj) modificati. Nel momento in cui qualcuno scaricherà il vostro progetto e tenterà di ricompilarlo, il task di MsBuild si occuperà di lanciare NuGet e scaricare tutti i file necessari per soddisfare le dipendenze. Ovviamente, è richiesta una connessione ad Internet!

Attenzione! La versione 1.6 di NuGet ha un problema con il certificato digitale con cui è stata firmata l’estensione: il risultato è che, se cercherete di aggiornarlo tramite l’Extension Manager di Visual Studio, la procedura fallirà. In questo caso, la procedura corretta è quella di disinstallare NuGet (dovrete avviare Visual Studio con permessi amministrativi) e poi reinstallarlo, sempre tramite l’Extension Manager (raggiungibile dal menu Tools di Visual Studio).

by Il blog di Matteo Pagani on 2/5/2012
Post archive