Note sulla versione di NuGet 1.2
Note sulla versione | di NuGet 1.0 e 1.1 NuGet 1.3
NuGet 1.2 è stato rilasciato il 30 marzo 2011.
Fin dall'inizio, NuGet supportava la presenza di librerie destinate a framework diversi. Ma ora i pacchetti possono contenere assembly destinati a profili specifici, ad esempio il profilo di Windows Telefono. Per specificare come destinazione un profilo specifico di un framework, aggiungere un trattino seguito dall'abbreviazione del profilo. Ad esempio, per impostare come destinazione SilverLight in esecuzione in un windows Telefono (noto anche come Windows Telefono 7), è possibile inserire un assembly nella cartella sl3-wp, come illustrato nello screenshot seguente.
Potresti chiedere perché non abbiamo semplicemente scelto di usare "wp7" come moniker. In parte, prevediamo che Windows Telefono 7 potrebbe eseguire una versione più recente di Silverlight in futuro, nel qual caso potrebbe essere necessario essere più specifici sul profilo del framework di destinazione.
Quando si installa un pacchetto con assembly denominati sicuri, NuGet può ora rilevare i casi in cui il progetto richiede l'aggiunta di reindirizzamenti di binding al file di configurazione per consentire al progetto di compilare e aggiungerli automaticamente. La parte 3 della serie di post di blog di David Ebbo sul controllo delle versioni di NuGet intitolata "Unification via Binding Redirects" illustra lo scopo di questa funzionalità in altri dettagli.
In alcuni casi, un pacchetto può dipendere da un assembly che si trova in .NET Framework. In senso stretto, non è sempre necessario che il consumer del pacchetto faccia riferimento all'assembly del framework. In alcuni casi, tuttavia, è importante, ad esempio quando lo sviluppatore deve scrivere codice su tipi in tale assembly per usare il pacchetto. Il nuovo frameworkAssemblies
elemento, un elemento figlio dell'elemento di metadati, consente di specificare un set di frameworkAssembly
elementi che puntano a un assembly Framework nella GAC. Si noti l'enfasi sull'assembly framework.
Questi assembly non sono inclusi nel pacchetto perché si presuppone che si trovino in ogni computer come parte di .NET Framework. Nella tabella seguente sono elencati gli attributi dell'elemento frameworkAssembly
.
Attributo | Descrizione |
---|---|
assemblyName | Obbligatorio. Nome dell'assembly, System.Net ad esempio . |
targetFramework | Facoltativo. Consente di specificare un framework e un nome di profilo (o alias) a cui si applica questo assembly del framework, ad esempio "net40" o "sl4". Usa lo stesso formato descritto in Supporto di più framework di destinazione. |
<frameworkAssemblies>
<frameworkAssembly assemblyName="System.ComponentModel.DataAnnotations" targetFramework="net40" />
<frameworkAssembly assemblyName="System.ServiceModel" targetFramework="net40" />
</frameworkAssemblies>
Quando si usa lo strumento da riga di comando nuget.exe, è ora possibile usare il comando SetApiKey per archiviare la chiave API. In questo modo, non è necessario specificarlo ogni volta che si esegue il push di un pacchetto. Per altre informazioni sul salvataggio della chiave API con nuget.exe, vedere la documentazione relativa alla pubblicazione di un pacchetto.
Package Explorer è stato aggiornato per supportare NuGet 1.2. Per altre informazioni, vedere .[Package Explorer release notes](http://nuget.codeplex.com/wikipage?title=New%20features%20in%20NuGet%20Package%20Explorer%201.0)
L'elenco precedente era il più evidente delle numerose funzionalità implementate e i bug risolti. Tutto in tutto, è stato implementato/risolto [59 work items](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=All&type=All&priority=All&release=NuGet%201.2&assignedTo=All&component=All&sortField=Votes&sortDirection=Descending&page=0)
in questa versione.
- 1.2 Incompatibilità dei pacchetti: i pacchetti compilati con la versione più recente dello strumento da riga di comando, nuget.exe (> 1.2) non funzioneranno con le versioni precedenti del componente aggiuntivo Vs NuGet (ad esempio 1.1). Se si verifica un messaggio di errore che indica qualcosa sullo schema incompatibile, si verifica questo errore. Aggiornare NuGet alla versione più recente.
- Incompatibilità di NuGet.Server: se si ospita un feed NuGet interno usando il progetto NuGet.Server, è necessario aggiornare il progetto con la versione più recente di NuGet.Server.
- Errore di mancata corrispondenza della firma: se si verifica un errore durante un aggiornamento con un messaggio relativo a una mancata corrispondenza della firma, è prima necessario disinstallare NuGet e quindi installarlo. Questa opzione è elencata nella pagina Problemi noti che fornisce altri dettagli. Il problema riguarda solo quelli che eseguono Visual Studio 2010 SP1 e hanno una versione di NuGet 1.0 installata in modo non corretto. Questa versione è stata resa disponibile solo dal sito Web CodePlex per un breve periodo, quindi questo problema non dovrebbe influire su troppe persone.