Note sulla versione di NuGet 2.1

Note | sulla versione di NuGet 2.0 NuGet 2.2

NuGet 2.1 è stato rilasciato il 4 ottobre 2012.

Nuget.Config gerarchico

NuGet 2.1 offre maggiore flessibilità nel controllo delle impostazioni NuGet tramite l'avvio ricorsivo della struttura di cartelle che cerca NuGet.Config i file e quindi la compilazione della configurazione dal set di tutti i file trovati. Si consideri, ad esempio, lo scenario in cui un team dispone di un repository di pacchetti interno per le compilazioni CI di altre dipendenze interne. La struttura di cartelle per un singolo progetto potrebbe essere simile alla seguente:

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

Inoltre, se il ripristino del pacchetto è abilitato per la soluzione, esisterà anche la cartella seguente:

C:\myteam\solution1\.nuget

Per rendere disponibile il repository di pacchetti interni del team per tutti i progetti su cui lavora il team, senza renderlo disponibile per ogni progetto nel computer, è possibile creare un nuovo file Nuget.Config e inserirlo nella cartella c:\myteam. Non è possibile specificare una cartella dei pacchetti per ogni progetto.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

È ora possibile notare che l'origine è stata aggiunta eseguendo il comando "nuget.exe sources" da qualsiasi cartella sotto c:\myteam, come illustrato di seguito:

NuGet.Config i file vengono cercati nell'ordine seguente:

1. .nuget\Nuget.Config
2. Procedura ricorsiva dalla cartella del progetto alla radice
3. Globale Nuget.Config (%appdata%\NuGet\Nuget.Config)

Le configurazioni vengono applicate nell'ordine inverso, vale a dire che in base all'ordinamento precedente, il file Nuget.Config globale verrà applicato per primo, seguito dai file Nuget.Config individuati dalla cartella radice alla cartella del progetto, seguita da .nuget\Nuget.Config. Ciò è particolarmente importante se si usa l'elemento <clear/> per rimuovere un set di elementi dalla configurazione.

Specificare il percorso della cartella 'packages'

In passato, NuGet ha gestito i pacchetti di una soluzione da una cartella 'packages' nota che si trova sotto la cartella radice della soluzione. Per i team di sviluppo che hanno molte soluzioni diverse in cui sono installati pacchetti NuGet, questo può comportare l'installazione dello stesso pacchetto in molte posizioni diverse nel file system.

NuGet 2.1 offre un controllo più granulare sulla posizione della cartella dei pacchetti tramite l'elemento repositoryPath nel NuGet.Config file. Basandosi sull'esempio precedente del supporto gerarchico di Nuget.Config, si supponga di voler avere tutti i progetti in C:\myteam\ condividere la stessa cartella dei pacchetti. A tale scopo, aggiungere semplicemente la voce seguente a c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

In questo esempio, il file condiviso Nuget.Config specifica una cartella di pacchetti condivisi per ogni progetto creato sotto C:\myteam, indipendentemente dalla profondità. Si noti che se si dispone di una cartella di pacchetti esistente sotto la radice della soluzione, è necessario eliminarla prima che NuGet inserisca i pacchetti nel nuovo percorso.

Supporto per librerie portabili

Le librerie portabili sono una funzionalità introdotta per la prima volta con .NET 4 che consente di creare assembly che possono funzionare senza modifiche su piattaforme Microsoft diverse, dalle versioni di the.NET Framework a Silverlight a Windows Telefono e anche Xbox 360 (anche se in questo momento NuGet non supporta la destinazione della libreria portatile Xbox). Estendendo le convenzioni dei pacchetti per le versioni e i profili del framework, NuGet 2.1 supporta ora librerie portabili consentendo di creare pacchetti con cartelle di destinazione lib del framework e del profilo composte.

Si considerino ad esempio le piattaforme di destinazione disponibili della libreria di classi portabile seguente.

Dopo aver compilato la libreria e aver eseguito il comando nuget.exe pack MyPortableProject.csproj , è possibile visualizzare la nuova struttura di cartelle del pacchetto della libreria portabile esaminando il contenuto del pacchetto NuGet generato.

Come si può notare, la convenzione di nome della cartella della libreria portabile segue il modello 'portable-{framework 1}+{framework n}' in cui gli identificatori del framework seguono le convenzioni di versione e nome del framework esistenti. Nell'identificatore del framework usato per Windows Telefono è presente un'eccezione alle convenzioni di nome e versione. Questo moniker deve usare il nome del framework 'wp' (wp7, wp71 o wp8). L'uso di "silverlight-wp7", ad esempio, genererà un errore.

Quando si installa il pacchetto creato da questa struttura di cartelle, NuGet può ora applicare il framework e le regole del profilo a più destinazioni, come specificato nel nome della cartella. Dietro le regole di corrispondenza di NuGet è il principio che le destinazioni "più specifiche" avranno la precedenza su quelle "meno specifiche". Ciò significa che i moniker destinati a una piattaforma specifica saranno sempre preferiti rispetto a quelli portabili se sono entrambi compatibili con un progetto. Inoltre, se più destinazioni portabili sono compatibili con un progetto, NuGet preferisce quello in cui il set di piattaforme supportate è "più vicino" al progetto che fa riferimento al pacchetto.

Destinazione di progetti Windows 8 e Windows Telefono 8

Oltre ad aggiungere il supporto per i progetti di libreria portabile, NuGet 2.1 fornisce nuovi moniker del framework per i progetti Windows 8 Store e Windows Telefono 8, nonché alcuni nuovi moniker generali per Windows Store e i progetti windows Telefono che saranno più facili da gestire nelle versioni future delle rispettive piattaforme.

Per le applicazioni Windows 8 Store, gli identificatori sono simili ai seguenti:

NuGet 2.0 e versioni precedenti	NuGet 2.1
winRT45, . NETCore45	Windows, Windows8, win, win8

Per i progetti di Windows Telefono, gli identificatori sono simili ai seguenti:

Telefono sistema operativo	NuGet 2.0 e versioni precedenti	NuGet 2.1
Windows Phone 7	silverlight3-wp	wp, wp7, Windows Telefono, Windows Telefono 7
Windows Telefono 7.5 (Mango)	silverlight4-wp71	wp71, Windows Telefono 71
Windows Phone 8	(non supportato)	wp8, Windows Telefono 8

In tutte le modifiche precedenti, i nomi dei framework precedenti continueranno a essere completamente supportati da NuGet 2.1. In futuro, i nuovi nomi devono essere usati in quanto saranno più stabili nelle versioni future delle rispettive piattaforme. I nuovi nomi non saranno supportati nelle versioni di NuGet precedenti alla 2.1, quindi pianificare di conseguenza quando effettuare il passaggio.

Ricerca migliorata nella finestra di dialogo Gestione pacchetti

Nelle ultime diverse iterazioni sono state introdotte modifiche alla raccolta NuGet che migliorano notevolmente la velocità e la pertinenza delle ricerche nei pacchetti. Tuttavia, questi miglioramenti sono stati limitati al sito Web nuget.org. NuGet 2.1 rende disponibile l'esperienza di ricerca migliorata tramite la finestra di dialogo Gestione pacchetti NuGet. Si supponga, ad esempio, di voler trovare il pacchetto di anteprima di Memorizzazione nella cache di Windows Azure. Una query di ricerca ragionevole per questo pacchetto può essere "Cache di Azure". Nelle versioni precedenti della finestra di dialogo gestione pacchetti, il pacchetto desiderato non verrebbe nemmeno elencato nella prima pagina dei risultati. Tuttavia, in NuGet 2.1 il pacchetto desiderato viene ora visualizzato nella parte superiore dei risultati della ricerca.

Forzare l'aggiornamento dei pacchetti

Prima di NuGet 2.1, NuGet ignorava l'aggiornamento di un pacchetto quando non era presente un numero di versione elevato. Ciò ha introdotto attriti per determinati scenari, in particolare nel caso di scenari di compilazione o integrazione continua in cui il team non vuole incrementare il numero di versione del pacchetto con ogni build. Il comportamento desiderato era quello di forzare un aggiornamento indipendentemente. NuGet 2.1 risolve questo problema con il flag 'reinstall' . Ad esempio, le versioni precedenti di NuGet generano quanto segue quando si tenta di aggiornare un pacchetto che non ha una versione del pacchetto più recente:

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

Con il flag reinstallazione, il pacchetto verrà aggiornato indipendentemente dal fatto che sia presente una versione più recente.

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

Un altro scenario in cui il flag di reinstallazione dimostra un vantaggio è quello della ridenozione del framework. Quando si modifica il framework di destinazione di un progetto (ad esempio, da .NET 4 a .NET 4.5), Update-Package -Reinstall può aggiornare i riferimenti agli assembly corretti per tutti i pacchetti NuGet installati nel progetto.

Modificare le origini dei pacchetti in Visual Studio

Nelle versioni precedenti di NuGet, l'aggiornamento di un'origine del pacchetto dalla finestra di dialogo delle opzioni di Visual Studio richiede l'eliminazione e la nuova aggiunta dell'origine del pacchetto. NuGet 2.1 migliora questo flusso di lavoro supportando l'aggiornamento come funzione di prima classe dell'interfaccia utente di configurazione.

Correzioni di bug

NuGet 2.1 include molte correzioni di bug. Per un elenco completo degli elementi di lavoro corretti in NuGet 2.0, visualizzare .[NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0)