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)

When will the golden age of “The Developer” end?

http://antjanus.com/blog/development/will-golden-age-developer-end/

OUYA: console giochi per tutti

Volete cimentarvi nella scrittura di un gioco?
Bene, c'è una nuova console che mette a disposizione tutto quanto necessario per lo sviluppo, senza sborsare un singolo euro.
OUYA è appunto questo: una console cheap (costa solo 99$) basata su sistema operativo Android, che mette a disposizione degli sviluppatori tutto l'SDK necessario.
Per sviluppare i giochi non è necessario comprare la console, perché basta l'emulatore, anche se ovviamente il test finale sulla console penso sia un passaggio dovuto.
Questo permette di iniziare da subito a sviluppare il gioco e minimizzare i costi.
Penso che possa valere la pena provare, magari in tempi di crisi qualche soldo può arrivare :-D

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.