Partager via


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) – Suppression du suffixe $metadata lors de la persistance des identifiants du flux.
  3. [Filip De Vos](https://www.codeplex.com/site/users/view/FilipDeVos) (@foxtricks)
    • [#3538](http://nuget.codeplex.com/workitem/3538) – Prise en charge de la spécification du fichier projet pour la commande nuget.exe update.
  4. [Juan Gonzalez](https://www.codeplex.com/site/users/view/jjgonzalez)
    • [#3536](http://nuget.codeplex.com/workitem/3536) – Jetons de remplacement non 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 lance OutOfMemoryException lors de l’envoi (push) d’un package volumineux.
  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) – Possibilité d’installer 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) – Suppression des 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 et autres.
    • Ce travail s’est déroulé sur plusieurs mois, Gregory travaillant avec nous sur le bon moment pour l’intégrer dans la branche master pour la version 2.8.

Résolution des correctifs pour les dépendances

Lors de la résolution des dépendances de package, NuGet a historiquement mis en œuvre une stratégie consistant à sélectionner la version majeure et mineure la plus basse du package qui satisfasse les dépendances du package. Contrairement aux versions majeure et mineure, toutefois, la version du correctif a toujours été résolue en fonction de la 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 le Developer1 et le Developer2 ont installé le PackageA@1.0.0, chacun s’est retrouvé avec une version différente du 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, le PackageB@1.0.0 serait installé à la suite de l’installation du PackageA@1.0.0, quelle que soit la version de correctif la plus récente.

Commutateur -DependencyVersion

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 avec la version la plus basse possible (comportement par défaut), la version la plus élevée possible, ou la version mineure ou de correctif la plus élevée. Ce commutateur fonctionne uniquement pour Install-Package dans la commande PowerShell.

DependencyVersion Switch

Attribut DependencyVersion

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 d’Install-Package. Cette valeur sera également respectée par la Boîte de dialogue du Gestionnaire de package NuGet pour toutes les opérations Install-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 graphes de dépendances profonds et, par conséquent, il peut être utile de voir d’abord ce qui va se passer lors d’une installation, d’une désinstallation ou d’une opération de mise à jour. NuGet 2.8 ajoute le commutateur -whatif PowerShell standard aux commandes Install-Package, Uninstall-Package et Update-Package pour permettre de visualiser l’intégralité de la fermeture des packages auxquels la commande sera appliquée. Par exemple, l’exécution de 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

Passage à la version antérieure du package

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 restaurer la dernière version stable. Avant NuGet 2.8, il s’agissait d’un processus en plusieurs étapes de désinstallation de la version préliminaire du package 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 des 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 developmentDependency. Une fois installées, ces métadonnées sont également ajoutées au fichier packages.config du projet dans lequel le package a été installé. Lorsque ce fichier packages.config 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 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 fichiers packages.config pour différents fichiers projet spécifiques à chaque plateforme.

Multiple package.config files

Revenir au cache local (cache de secours)

Bien que les packages NuGet soient généralement consommés à partir d’une galerie à distance, 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 cache de secours automatique à la console du gestionnaire de package. 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 cache de secours ne nécessite aucun argument de commande spécifique. En outre, le cache de secours ne fonctionne actuellement que dans la console du gestionnaire de package : le comportement ne fonctionne pas actuellement dans la boîte de dialogue du gestionnaire de package.

Mises à jour de WebMatrix NuGet Client

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. Parmi les nouvelles fonctionnalités figurent notamment « Update All » (Tout mettre à jour), « Minimum NuGet Version » (Version NuGet minimale) et la possibilité de remplacer des fichiers de contenu.

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

  1. Ouvrez 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. Fermez et redémarrez 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é fourni par Microsoft dans le projet NuGet open source. Auparavant, l’intégration NuGet était incorporée à WebMatrix et elle ne pouvait pas ê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.

Correctifs de bogues

L’un des principaux correctifs de bogues effectués a été l’amélioration des performances dans la commande Update-Package -Reinstall.

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