Note sulla versione di NuGet 2.5

Note sulla versione | di NuGet 2.2.1 NuGet 2.6

NuGet 2.5 è stato rilasciato il 25 aprile 2013. Questa versione era così grande, ci siamo sentiti costretti a saltare le versioni 2.3 e 2.4! Fino ad oggi, questa è la versione più grande che abbiamo avuto per NuGet, con oltre [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) nella versione.

Riconoscimenti

Si vuole ringraziare i seguenti collaboratori esterni per i contributi significativi a NuGet 2.5:

1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
   • [#2847](https://nuget.codeplex.com/workitem/2847) - Aggiungere MonoAndroid, MonoTouch e MonoMac all'elenco di identificatori del framework di destinazione noti.
2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
   • [#2865](https://nuget.codeplex.com/workitem/2865) - Correzione dell'ortografia di NuGet.targets per un sistema operativo con distinzione tra maiuscole e minuscole
3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
   • Creare la soluzione in Mono.
4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
   • Correzione dell'esito negativo degli unit test in Mono.
5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
   • [#2920](https://nuget.codeplex.com/workitem/2920) - nuget.exe comando pack non propaga proprietà a MSBuild
6. [Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos) (@bajtos)
   • [#1511](https://nuget.codeplex.com/workitem/1511) - Codice di gestione XML modificato per mantenere la formattazione.
7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
   • Aggiunta di parole riconosciute al dizionario personalizzato per consentire build.cmd di avere esito positivo.
8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
   • Correggere gli unit test durante l'esecuzione in Visual Studio localizzato.
9. [Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
   • Interfaccia estratta da PackageService
10. [Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou) (@brugidou)
    • [#936](https://nuget.codeplex.com/workitem/936) - Gestire le dipendenze del progetto durante la compressione
11. [Xavier Decoster](https://www.codeplex.com/site/users/view/XavierDecoster) (@XavierDecoster)
    • [#2991](https://nuget.codeplex.com/workitem/2991), [#3164](https://nuget.codeplex.com/workitem/3164) - Supportare la password cancella testo quando si archiviano le credenziali di origine del pacchetto nei file nuget.cofig
12. [James Manning](http://www.codeplex.com/site/users/view/jmanning) (@manningj)
    • [#3190](http://nuget.codeplex.com/workitem/3190), [#3191](https://nuget.codeplex.com/workitem/3191) - Correzione della descrizione della Guida di Get-Package

Microsoft apprezza anche i seguenti utenti per la ricerca di bug con NuGet 2.5 Beta/RC approvati e risolti prima della versione finale:

1. [Tony Wall](https://www.codeplex.com/site/users/view/CodeChief) (@CodeChief)
   • [#3200](https://nuget.codeplex.com/workitem/3200) - MSTest interrotto con le build NuGet 2.4 e 2.5 più recenti

Funzionalità rilevanti nella versione

Consenti agli utenti di sovrascrivere i file di contenuto già esistenti

Una delle funzionalità più richieste di tutti i tempi è stata la possibilità di sovrascrivere i file di contenuto già esistenti sul disco quando è incluso in un pacchetto NuGet. A partire da NuGet 2.5, questi conflitti vengono identificati e viene richiesto di sovrascrivere i file, mentre in precedenza questi file venivano sempre ignorati.

'nuget.exe update' e 'Install-Package' dispongono ora di una nuova opzione '-FileConflictAction' per impostare alcune impostazioni predefinite per gli scenari della riga di comando.

Impostare un'azione predefinita quando un file di un pacchetto esiste già nel progetto di destinazione. Impostare su "Sovrascrivi" per sovrascrivere sempre i file. Impostare su "Ignora" per ignorare i file. Se non specificato, verrà richiesto per ogni file in conflitto.

Importazione automatica di file di destinazioni e props di MSBuild

È stata creata una nuova cartella convenzionale al livello superiore del pacchetto NuGet. Come peer to \lib, \contente \tools, è ora possibile includere una \build cartella nel pacchetto. In questa cartella è possibile inserire due file con nomi fissi o {packageid}.targets{packageid}.props. Questi due file possono essere direttamente in build o in cartelle specifiche del framework proprio come le altre cartelle. La regola per la selezione della cartella del framework più corrispondente è esattamente la stessa di quelle in quelle.

Quando NuGet installa un pacchetto con \build files, aggiungerà un elemento MSBuild <Import> nel file di progetto che punta ai .targets file e .props . Il .props file viene aggiunto nella parte superiore, mentre il .targets file viene aggiunto in basso.

Specificare riferimenti diversi per ogni piattaforma tramite <References/> elemento

Prima della versione 2.5, nel .nuspec file, l'utente può specificare solo i file di riferimento da aggiungere per tutti i framework. Ora con questa nuova funzionalità nella versione 2.5, l'utente può creare l'elemento <reference/> per ogni piattaforma supportata, ad esempio:

<references>
    <group targetFramework="net45">
        <reference file="a.dll" />
    </group>
    <group targetFramework="netcore45">
        <reference file="b.dll" />
    </group>
    <group>
        <reference file="c.dll" />
    </group>
</references>

Ecco il flusso per il modo in cui NuGet aggiunge riferimenti ai progetti in base al .nuspec file:

1. Trovare la lib cartella appropriata per il framework di destinazione e ottenere l'elenco di assembly da tale cartella
2. Trovare separatamente il gruppo di riferimenti appropriato per il framework di destinazione e ottenere l'elenco di assembly da tale gruppo. Il gruppo di riferimento senza framework di destinazione specificato è il gruppo di fallback.
3. Trovare l'intersezione dei due elenchi e usarla come riferimenti da aggiungere

Questa nuova funzionalità consentirà agli autori di pacchetti di usare la funzionalità Riferimenti per applicare subset di assembly a framework diversi quando altrimenti sarebbe necessario portare assembly duplicati in più lib cartelle.

Nota: è necessario usare attualmente nuget.exe pack per usare questa funzionalità; Esplora pacchetti NuGet non lo supporta ancora.

Pulsante Aggiorna tutto per consentire l'aggiornamento di tutti i pacchetti contemporaneamente

Molti di voi conoscono il cmdlet di PowerShell "Update-Package" per aggiornare tutti i pacchetti; ora c'è un modo semplice per eseguire questa operazione anche tramite l'interfaccia utente.

Per provare questa funzionalità:

1. Creare una nuova applicazione MVC ASP.NET
2. Avviare la finestra di dialogo "Gestisci pacchetti NuGet"
3. Selezionare "Aggiornamenti"
4. Fare clic sul pulsante "Aggiorna tutto"

Supporto dei riferimenti al progetto migliorato per nuget.exe Pack

Ora nuget.exe comando pack elabora i progetti a cui si fa riferimento con le regole seguenti:

1. Se il progetto a cui si fa riferimento ha un file corrispondente .nuspec , ad esempio è presente un file denominato proj1.nuspec nella stessa cartella di proj1.csproj, questo progetto viene aggiunto come dipendenza al pacchetto, usando l'ID e la .nuspec versione letti dal file.
2. In caso contrario, i file del progetto a cui si fa riferimento vengono raggruppati nel pacchetto. I progetti a cui fa riferimento questo progetto verranno quindi elaborati usando le stesse regole in modo ricorsivo.
3. Vengono aggiunti tutti i file DLL, .pdbe .exe .
4. Vengono aggiunti tutti gli altri file di contenuto.
5. Tutte le dipendenze vengono unite.

In questo modo un progetto a cui si fa riferimento può essere considerato come dipendenza se è presente un .nuspec file, altrimenti diventa parte del pacchetto.

Altri dettagli sono disponibili qui: [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)

Aggiungere una proprietà "Versione minima nuGet" ai pacchetti

Un nuovo attributo di metadati denominato "minClientVersion" ora può indicare la versione minima del client NuGet necessaria per utilizzare un pacchetto.

Questa funzionalità consente all'autore del pacchetto di specificare che un pacchetto funzionerà solo dopo una determinata versione di NuGet. Man mano che vengono aggiunte nuove .nuspec funzionalità dopo NuGet 2.5, i pacchetti saranno in grado di richiedere una versione minima di NuGet.

<metadata minClientVersion="2.6">

Se l'utente dispone di NuGet 2.5 installato e un pacchetto viene identificato come che richiede la versione 2.6, verranno forniti segnali visivi all'utente che indica che il pacchetto non sarà installabile. L'utente verrà quindi guidato per aggiornare la versione di NuGet.

Ciò migliorerà sull'esperienza esistente in cui i pacchetti iniziano a essere installati, ma non riescono a indicare che è stata identificata una versione dello schema non riconosciuta.

Le dipendenze non vengono più aggiornate inutilmente durante l'installazione del pacchetto

Prima di NuGet 2.5, quando è stato installato un pacchetto che dipende da un pacchetto già installato nel progetto, la dipendenza verrà aggiornata come parte della nuova installazione, anche se la versione esistente ha soddisfatto la dipendenza.

A partire da NuGet 2.5, se una versione di dipendenza è già soddisfatta, la dipendenza non verrà aggiornata durante altre installazioni di pacchetti.

Scenario:

1. Il repository di origine contiene il pacchetto B con la versione 1.0.0 e 1.0.2. Contiene anche il pacchetto A che ha una dipendenza da B (>= 1.0.0).
2. Si supponga che il progetto corrente abbia già installato il pacchetto B versione 1.0.0. A questo momento si vuole installare il pacchetto A.

In NuGet 2.2 e versioni precedenti:

• Quando si installa il pacchetto A, NuGet aggiornerà automaticamente B alla versione 1.0.2, anche se la versione esistente 1.0.0 soddisfa già il vincolo di versione delle dipendenze, ovvero >= 1.0.0.

In NuGet 2.5 e versioni successive:

• NuGet non aggiornerà più B, perché rileva che la versione esistente 1.0.0 soddisfa il vincolo di versione delle dipendenze.

Per altre informazioni su questa modifica, leggere i dettagli [work item](https://nuget.codeplex.com/workitem/1681) , nonché l'oggetto correlato [discussion thread](https://nuget.codeplex.com/discussions/436712).

nuget.exe restituisce richieste HTTP con dettagli dettagliati

Se si esegue la risoluzione dei problemi nuget.exe o si è semplicemente curiosi delle richieste HTTP eseguite durante le operazioni, l'opzione "-verbosity detailed" restituirà ora tutte le richieste HTTP effettuate.

nuget.exe push supporta ora origini UNC e cartelle

Prima di NuGet 2.5, se si è tentato di eseguire "nuget.exe push" in un'origine del pacchetto in base a un percorso UNC o a una cartella locale, il push avrà esito negativo. Con la funzionalità di configurazione gerarchica aggiunta di recente, era diventato comune per nuget.exe dover avere come destinazione un'origine UNC/cartella o una raccolta NuGet basata su HTTP.

A partire da NuGet 2.5, se nuget.exe identifica un'origine UNC/cartella, eseguirà la copia del file nell'origine.

Il comando seguente funzionerà ora:

nuget push -source \\mycompany\repo\ mypackage.1.0.0.nupkg

nuget.exe supporta i file di configurazione specificati in modo esplicito

nuget.exe comandi che accedono alla configurazione (tutti tranne 'spec' e 'pack') supportano ora una nuova opzione '-ConfigFile', che impone l'uso di un file di configurazione specifico al posto del file di configurazione predefinito in %AppData%\nuget\Nuget.Config.

Esempio:

nuget sources add -name test -source http://test -ConfigFile C:\test\.nuget\Nuget.Config

Supporto per progetti nativi

Con NuGet 2.5, gli strumenti NuGet sono ora disponibili per i progetti nativi in Visual Studio. La maggior parte dei pacchetti nativi utilizzerà la funzionalità di importazione di MSBuild precedente, usando uno strumento creato dal progetto CoApp. Per altre informazioni, leggere i dettagli sullo strumento nel sito Web di coapp.org.

Il nome del framework di destinazione "nativo" viene introdotto per i pacchetti per includere i file in \build, \content e \tools quando il pacchetto viene installato in un progetto nativo. La cartella 'lib' non viene usata per i progetti nativi.