Notes de publication de NuGet 2.8

Notes de publication de NuGet 2.7.2 | Notes de publication de NuGet 2.8.1

NuGet 2.8 a été publié le 29 janvier 2014.

Remerciements

1. [Llewellyn Pritchard](https://www.codeplex.com/site/users/view/leppie) (@leppie)
   • [#3466](https://nuget.codeplex.com/workitem/3466) - Lors de l’empaquetage de packages, vérification de l’ID des packages de dépendances.
2. [Maarten Balliauw](https://www.codeplex.com/site/users/view/maartenba) (@maartenballiauw)
   • [#2379](https://nuget.codeplex.com/workitem/2379) - Supprimez le suffixe $metadata lors de la persistage des informations d’identification du flux.
3. [Filip De Vos](https://www.codeplex.com/site/users/view/FilipDeVos) (@foxtricks)
   • [#3538](http://nuget.codeplex.com/workitem/3538) - Support de la spécification du fichier projet pour la commande de mise à jour nuget.exe.
4. [Juan Gonzalez](https://www.codeplex.com/site/users/view/jjgonzalez)
   • [#3536](http://nuget.codeplex.com/workitem/3536) - Les jetons de remplacement n'ont pas été transmis avec -IncludeReferencedProjects.
5. [David Poole](https://www.codeplex.com/site/users/view/Sarkie) (@Sarkie_Dave)
   • [#3677](http://nuget.codeplex.com/workitem/3677) - Correction de nuget.push qui génère OutOfMemoryException lors du push d’un package de grande taille.
6. [Wouter Ouwens](https://www.codeplex.com/site/users/view/Despotes)
   • [#3666](http://nuget.codeplex.com/workitem/3666) - Correction d’un chemin cible incorrect lorsque le projet fait référence à un autre projet CLI/C++.
7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
   • [#3639](https://nuget.codeplex.com/workitem/3639) - Autoriser l’installation des packages en tant que dépendances de développement par défaut
8. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
   • [#3717](https://nuget.codeplex.com/workitem/3717) - Supprimer les mises à niveau implicites vers la dernière version du correctif
9. [Gregory Vandenbrouck](https://www.codeplex.com/site/users/view/vdbg)
   • Plusieurs correctifs de bogues et améliorations pour NuGet.Server, la commande nuget.exe miroir, etc.
   • Ce travail a été effectué au cours de plusieurs mois, avec Gregory travaillant avec nous sur le bon moment pour s’intégrer à master pour 2.8.

Résolution de patchs pour les dépendances

Lors de la résolution des dépendances de package, NuGet a implémenté historiquement une stratégie de sélection de la version de package principale et mineure la plus basse qui satisfait aux dépendances du package. Contrairement à la version principale et mineure, toutefois, la version corrective a toujours été résolue en version la plus élevée. Bien que le comportement ait été bien intentionné, il a créé un manque de déterminisme pour l’installation de packages avec des dépendances. Prenons l'exemple suivant :

PackageA@1.0.0 -[ >=1.0.0 ]-> PackageB@1.0.0

Developer1 installs PackageA@1.0.0: installed PackageA@1.0.0 and PackageB@1.0.0

PackageB@1.0.1 is published

Developer2 installs PackageA@1.0.0: installed PackageA@1.0.0 and PackageB@1.0.1

Dans cet exemple, même si Developer1 et Developer2 ont installé PackageA@1.0.0, chacun a fini par une version différente de PackageB. NuGet 2.8 modifie ce comportement par défaut afin que le comportement de résolution des dépendances pour les versions de correctifs soit cohérent avec le comportement des versions majeures et mineures. Dans l’exemple ci-dessus, PackageB@1.0.0 est installé suite à l’installation de PackageA@1.0.0, quelle que soit la version de correctif la plus récente.

-DependencyVersion Switch

Bien que NuGet 2.8 modifie le comportement par défaut pour la résolution des dépendances, il ajoute également un contrôle plus précis sur le processus de résolution des dépendances via le commutateur -DependencyVersion dans la console du gestionnaire de package. Le commutateur permet de résoudre les dépendances vers la version la plus basse possible (comportement par défaut), la version la plus élevée possible, ou la version mineure ou corrective la plus élevée. Ce commutateur fonctionne uniquement pour install-package dans la commande PowerShell.

DependencyVersion, attribut

Outre le commutateur -DependencyVersion détaillé ci-dessus, NuGet a également permis de définir un nouvel attribut dans le fichier Nuget.Config définissant la valeur par défaut, si le commutateur -DependencyVersion n’est pas spécifié dans un appel de package d’installation. Cette valeur sera également respectée par la boîte de dialogue Gestionnaire de package NuGet pour toutes les opérations d’installation du package. Pour définir cette valeur, ajoutez l’attribut ci-dessous à votre fichier Nuget.Config :

<config>
    <add key="dependencyversion" value="Highest" />
</config>

Aperçu des opérations NuGet avec -whatif

Certains packages NuGet peuvent avoir des graphiques de dépendances profonds et, par conséquent, il peut être utile pendant une opération d’installation, de désinstallation ou de mise à jour pour voir d’abord ce qui se passera. NuGet 2.8 ajoute le commutateur PowerShell standard -whatif aux commandes install-package, uninstall-package et update-package pour permettre de visualiser toute la fermeture des packages auxquels la commande sera appliquée. Par exemple, l’exécution install-package Microsoft.AspNet.WebApi -whatif dans une application web ASP.NET vide génère les résultats suivants.

PM> install-package Microsoft.AspNet.WebApi -whatif
Attempting to resolve dependency 'Microsoft.AspNet.WebApi.WebHost (≥ 5.0.0)'.
Attempting to resolve dependency 'Microsoft.AspNet.WebApi.Core (≥ 5.0.0)'.
Attempting to resolve dependency 'Microsoft.AspNet.WebApi.Client (≥ 5.0.0)'.
Attempting to resolve dependency 'Newtonsoft.Json (≥ 4.5.11)'.
Install Newtonsoft.Json 4.5.11
Install Microsoft.AspNet.WebApi.Client 5.0.0
Install Microsoft.AspNet.WebApi.Core 5.0.0
Install Microsoft.AspNet.WebApi.WebHost 5.0.0
Install Microsoft.AspNet.WebApi 5.0.0

Package de rétrogradation

Il n’est pas rare d’installer une version préliminaire d’un package afin d’examiner les nouvelles fonctionnalités, puis de décider de revenir à la dernière version stable. Avant NuGet 2.8, il s’agissait d’un processus en plusieurs étapes de désinstallation du package de préversion et de ses dépendances, puis d’installation de la version antérieure. Avec NuGet 2.8, toutefois, le package de mise à jour restaure désormais l’intégralité de la fermeture du package (par exemple, l’arborescence des dépendances du package) vers la version précédente.

Dépendances de développement

De nombreux types de fonctionnalités différents peuvent être fournis en tant que packages NuGet, y compris les outils utilisés pour optimiser le processus de développement. Ces composants, bien qu’ils puissent être déterminants dans le développement d’un nouveau package, ne doivent pas être considérés comme une dépendance du nouveau package lorsqu’il est publié ultérieurement. NuGet 2.8 permet à un package de s'identifier dans le fichier .nuspec en tant que dépendance de développement. Une fois installées, ces métadonnées sont également ajoutées au packages.config fichier du projet dans lequel le package a été installé. Lorsque ce packages.config fichier est analysé ultérieurement pour les dépendances NuGet pendant nuget.exe pack, il exclut ces dépendances marquées comme dépendances de développement.

Fichiers de packages.config individuels pour différentes plateformes

Lors du développement d’applications pour plusieurs plateformes cibles, il est courant d’avoir différents fichiers projet pour chacun des environnements de build respectifs. Il est également courant de consommer différents packages NuGet dans différents fichiers projet, car les packages ont différents niveaux de prise en charge pour différentes plateformes. NuGet 2.8 offre une prise en charge améliorée de ce scénario en créant différents packages.config fichiers pour différents fichiers projet spécifiques à la plateforme.

Repli au cache local

Bien que les packages NuGet soient généralement consommés à partir d’une galerie distante, comme la galerie NuGet à l’aide d’une connexion réseau, il existe de nombreux scénarios où le client n’est pas connecté. Sans connexion réseau, le client NuGet n’a pas pu installer correctement les packages, même lorsque ces packages étaient déjà sur l’ordinateur du client dans le cache NuGet local. NuGet 2.8 ajoute le basculement automatique du cache à la console du gestionnaire de paquets. Par exemple, lors de la déconnexion de la carte réseau et de l’installation de jQuery, la console affiche les éléments suivants :

PM> Install-Package jquery
The source at nuget.org [https://www.nuget.org/api/v2/] is unreachable. Falling back to NuGet Local Cache at C:\Users\me\AppData\Local\NuGet\Cache
Installing 'jQuery 2.0.3'.
Successfully installed 'jQuery 2.0.3'.
Adding 'jQuery 2.0.3' to WebApplication18.
Successfully added 'jQuery 2.0.3' to WebApplication18.

La fonctionnalité de secours du cache ne nécessite aucun argument de commande spécifique. En outre, le repli du cache fonctionne actuellement uniquement dans la console du gestionnaire de paquets - le comportement ne fonctionne pas actuellement dans la boîte de dialogue du gestionnaire de paquets.

Mises à jour du client NuGet WebMatrix

Avec NuGet 2.8, l’extension NuGet pour WebMatrix a également été mise à jour pour inclure la plupart des principales fonctionnalités fournies avec NuGet 2.5. Les nouvelles fonctionnalités incluent celles telles que « Mettre à jour tout », « Version NuGet minimale » et permettre le remplacement des fichiers de contenu.

Pour mettre à jour votre extension Gestionnaire de package NuGet dans WebMatrix 3 :

1. Ouvrir WebMatrix 3
2. Cliquez sur l’icône Extensions dans le ruban
3. Sélectionnez l’onglet Mises à jour
4. Cliquez pour mettre à jour le Gestionnaire de package NuGet vers la version 2.5.0
5. Fermer et redémarrer WebMatrix 3

Il s’agit de la première version de l’équipe NuGet de l’extension Gestionnaire de package NuGet pour WebMatrix. Le code a récemment été contribué par Microsoft au projet NuGet open source. Auparavant, l’intégration de NuGet a été intégrée à WebMatrix et elle n’a pas pu être mise à jour hors bande de WebMatrix. Nous avons maintenant la possibilité de la mettre à jour en même temps que les autres outils clients de NuGet.

Les correctifs de bogues

L’un des principaux correctifs de bogues effectués a été l’amélioration des performances dans la commande -reinstall update-package.

Outre ces fonctionnalités et le correctif de performances mentionné ci-dessus, cette version de NuGet inclut également de nombreux autres correctifs de bogues. 181 problèmes totaux ont été résolus dans la version. Pour consulter la liste complète des éléments de travail corrigés dans NuGet 2.8, veuillez consulter le [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.8&status=all).