NuGet 3.0

E dopo un bel po' d'attesa, la nuova versione di NuGet è qui!
http://blog.nuget.org/20150720/nuget-3.0.0.html

NuGet: verifica delle dipendenze

Finora abbiamo visto come usare NuGet per usare, creare e pubblicare pacchetti per .Net.
Supponiamo ora di avere la necessità di controllare le dipendenze del nostro progetto, e dare l'allarme se pacchetti diversi non abbiano dipendenze comuni ma con differenti versioni.
NuGet mette a disposizione il pacchetto nuget.core, con una serie di API per operare a basso livello sulle dipendenze.
Per installarlo basta il comando

install-package nuget.core

Tra le 1.000 funzioni contenute in questo assembly (che ancora non ho scoperto a pieno) c'è appunto la gestione dei pacchetti.
In questo esempio, partendo da una directory locale, si mettono a video le dipendenze per ogni pacchetto ivi contenuto.
Se guardiamo l'output vediamo che il pacchetto MyCompany.Castle usa Castle.Core v2.5.2 Lo stesso pacchetto è usato da MyCompany.Versioning, fortunatamente con la stessa versione.
Una piccola modifica al programma ci può far individuare eventuali dipendenze con versioni diverse dello stesso pacchetto, ed aiutarci a non avere conflitti di dipendenza quando impacchettiamo i nostri software (o, come è capitato a me, avvisi a runtime di funzioni mancanti perché l'assembly più vecchio sovrascriveva il nuovo).

NuGet: pubblicare un pacchetto

Dopo aver creato un pacchetto NuGet è arrivata l'ora di usarlo e farlo usare ai vostri colleghi (altrimenti a cosa serve?)
Ci sono fondamentalmente 2 distinti tipi di pubblicazione: su un server pubblico, se stiamo facendo un progetto open, o su un server privato se stiamo creando qualcosa per uso interno.

Pubblicare su un server pubblico

Per poter pubblicare il nostro assembly sui server NuGet, abbiamo bisogno di creare un account. Una volta creato un account verrà generata una chiave. Per registrarla una volta per tutte sul client basterà digitare il comando
nuget setApiKey Your-API-Key

per la pubblicazione vera e propria basta invece invocare il comando
NuGet Push YourPackage.nupkg

Pubblicare su un server privato

Supponiamo invece di usare NuGet come gestore interno delle dipendenze dei progetti, e di non voler rilasciare come pubblici i nostri assembly. Come possiamo fare per avere un repository NuGet tutto per noi?
Possiamo mettere su un feed. I Feed NuGet possono essere di due tipi: locali, ospitati su un disco locale o di rete, oppure remoti, ospitati su un server Web.

Local Feed

Per gestire i local feed è sufficiente copiare in una directory i files .nupkg ed aggiungere in VisualStudio la directory alle sorgenti (oppure usare il comando nuget sources da prompt dei comandi :-D )
L'opzione di usare una directory condivisa è molto comoda per piccoli gruppi di lavoro, perché non necessita di particolari infrastrutture.

Remote Feed

Se si preferisce avere un server remoto per gestire i nostri feed dobbiamo fare un po' più di lavoro (non troppo per fortuna) ed avere un server IIS a disposizione.
Per prima cosa, con VisualStudio (o SharpDevelop) bisogna creare un progetto Web.
A questo progetto web dovremo aggiungere il riferimento NuGet a NuGet.Server. Questa installazione farà tutto il lavoro per noi, creando tutto ciò di cui abbiamo bisogno per la nostra Web Application.
Le uniche cose che dobbiamo eventualmente configurare sono, nel file App.config, il path ai pacchetti (key="packagesPath") e la apiKey o altri meccanismi di sicurezza.
Fatto questo, e distribuita l'applicazione sul server di riferimento, basterà aggiungere in VisualStudio il link al nostro repository (che sarà del tipo http://mioserver/miorepository)
Per pubblicare un qualsiasi pacchetto il procedimento sarà lo stesso che non verso i server NuGet (nuget push)

NuGet: personalizzare il file nuspec

Il file con estensione .nuspec serve a descrivere un pacchetto e viene inserito all'interno del pacchetto stesso.
Il file contiene una descrizione del pacchetto e, opzionalmente, una lista di files da includere. Se non viene specificato alcun file tutti i file e cartelle della directory vengono inclusi.
Guardando alla lista dei tag usabili, si notano i tag dependencies, references, frameworkAssemblies

dependencies

Con il tag dependencies si specificano i pacchetti da cui dipende il nostro pacchetto. Questo ci permette di includere ad esempio Log4Net come dipendenza del pacchetto che stiamo andando a creare. NuGet, quando scarica il pacchetto e lo aggiunge al progetto, scarica automaticamente le dipendenze e le aggiunge come reference al progetto. Dalla versione 2.0, NuGet permette di raggruppare le dipendenze, e di specificare il framework target per ognuna di esse. Versioni di framework diverse possono quindi avere dipendenze diverse.

references

Il tag references serve per esplicitare quali riferimenti verranno aggiunti al progetto. Il default per NuGet è aggiungere come riferimento ogni dll contenuta nella directory lib. Questo tag permette di includere solo determinati assemblies. Questo meccanismo è pensato per gli assembly design-time, che devono essere trovati da VisualStudio per poter funzionare correttamente, ma non devono essere copiati nell'output di compilazione.
Anche nel caso del tag references tutto può essere raggruppato per puntare a framework diversi.

frameworkAssemblies

si usa il tag frameworkAssemblies se si vuol specificare la dipendenza di un assembly dagli assembly del .Net Framework. Di solito non è necessario esplicitare questa dipendenza, ma ci possono essere casi in cui si debba "forzare" la dipendenza (mi viene in mente l'uso dell'assembly System.Web se si usa HttpWebRequest). Anche in questo caso si può specificare il targetFramework su cui si opera. Ovviamente questi files non vengono inclusi nel pacchetto compilato, perché si presume che siano presenti sulla macchina.

Oltre a questi tag si può gestire il tag files, per includere esplicitamente files. Il tag non è obbligatorio perché, seguendo le linee guida, tutti i files contenuti nella directory vengono inclusi. Anche in questo caso, è possibile esplicitare files diversi per framework diversi.
Da notare che i files NON sono soltanto dll già compilate, ma possono essere di qualsiasi tipo (ad esempio immagini o css per progetti web, sorgenti e quant'altro)

Una volta creato il file .nuspec, le directory e i files necessari, possiamo compilare il tutto, da prompt dei comandi, con un semplice

nuget pack myAssembly.nuspec

A questo punto non ci resta che pubblicare il pacchetto.

NuGet: creare i pacchetti

Conoscete Maven? Beh, NuGet sembra un po' la controparte di Maven per il mondo .Net
Ovviamente, essendo legato al mondo Microsoft, viene presentato come un'estensione di VisualStudio ("NuGet is a Visual Studio extension that makes it easy to add, remove, and update libraries and tools in Visual Studio projects that use the .NET Framework."), ma fortunatamente per me può essere usato anche come eseguibile prompt dei comandi. Lo so, sono il solito Nerd, ma il prompt dei comandi mi permette una maggior libertà di fare (o meglio far fare) quello che voglio.
Comunque, diciamo che NuGet, come Maven, lo si può vedere da 2 distinti punti di vista: quello dell'utilizzatore di pacchetti e quello del creatore di pacchetti.
Il primo punto di vista è banale: ho bisogno di un pacchetto per il mio progetto (ad esempio Log4Net)? Lo cerco tra tutti quelli disponibili e lo aggiungo. NuGet si occupa di scaricare quanto necessario, aggiungere i riferimenti al progetto e, se specificato, fare tutte le operazioni necessarie al progetto (ad esempio aggiungere un sorgente). Quando viene rilasciata una nuova versione del pacchetto posso aggiornare facilmente il tutto.

Bene, ma come faccio a creare un pacchetto?
Dalla documentazione, ho bisogno del prompt dei comandi (quando le cose si fanno difficili, i duri cominciano a giocare...) oppure avvalermi della GUI
Il comando da lanciare è Nuget spec  . Questo crea un file, con estensione .nuspec, relativo al file asseblyName.dll. Questo file è un manifest che descrive il contenuto di un pacchetto via XML. Qui ci sono le specifiche.
Posso quindi personalizzare il file, adattandolo alle esigenze, e poi impacchettare il tutto con il comando Nuget pack Otterrò così un file impacchettato myfile.nupkg pronto per essere pubblicato.
La pubblicazione di un pacchetto, la personalizzazione del file .nuspec e la verifica delle dipendenze saranno oggetto di altri articoli (spero con frequenza maggiore di quella fin qui avuta)