Lire en anglais

Partager via


Notes de publication de NuGet 2.7

Notes de publication de NuGet 2.6.1 pour WebMatrix | Notes de publication de NuGet 2.7.1

NuGet 2.7 a été publié le 22 août 2013.

Remerciements

Nous tenons à remercier les contributeurs externes suivants pour leurs importantes contributions à NuGet 2.7 :

  1. [Mike Roth](http://www.codeplex.com/site/users/view/mxrss) (@mxrss)
    • Affichez l’URL de licence lorsque la liste des packages et de la verbosité est détaillée.
  2. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • [#1956](http://nuget.codeplex.com/workitem/1956) - Ajouter l’attribut developmentDependency à packages.config et l’utiliser dans la commande pack pour inclure uniquement les packages d’exécution
  3. [Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael) (@tkrafael)
    • Évitez la clé de propriétés en duplicata dans la commande nuget.exe pack.
  4. [Ben Phegan](http://www.codeplex.com/site/users/view/benphegan) (@BenPhegan)
    • [#2610](http://nuget.codeplex.com/workitem/2610) - Augmentez la taille du cache de l’ordinateur à 200.
  5. [Slava Trenogin](http://www.codeplex.com/site/users/view/derigel) (@derigel)
    • [#3217](http://nuget.codeplex.com/workitem/3217) - Corriger la boîte de dialogue NuGet montrant les mises à jour sous l’onglet incorrect
    • Le correctif Project.TargetFramework peut être nul dans ProjectManager
    • [#3248](http://nuget.codeplex.com/workitem/3248) - Le correctif SharedPackageRepository FindPackage/FindPackagesById échoue sur un packageId inexistant
  6. [Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG) (@kevfromireland)
    • [#3234](http://nuget.codeplex.com/workitem/3234) - Activer le support du projet Nomad
  7. [Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie) (@corinblaikie)
    • [#3252](http://nuget.codeplex.com/workitem/3252) - La correction de la commande Push (Envoyer) échoue avec le code de sortie 0 lorsque le fichier n’existe pas.
  8. [Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
    • [#3226](http://nuget.codeplex.com/workitem/3226) - Correction d’un bogue avec la commande Add-BindingRedirect lorsqu’un projet fait référence à un projet de base de données.
  9. [Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos) (@bajtos)
    • [#2891](http://nuget.codeplex.com/workitem/2891)- Correction du bogue de nuget.pack analysant incorrectement le caractère générique dans l’attribut « exclude ».
  10. [Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981) (@zippy1981)
    • [#3307](http://nuget.codeplex.com/workitem/3307) - La correction du bogue NuGet.targets ne transfère pas $(Platform) à nuget.exe lors de la restauration de packages.
  11. [Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
    • [#3294](http://nuget.codeplex.com/workitem/3294) - Correction d’un bogue dans la commande de package nuget.exe qui autoriserait l’ajout de fichiers portant le même nom, mais une casse différente, provoquant finalement l’exception « Item already exists » (Élément déjà existant).
  12. [Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino) (@kzu)
    • [#2990](http://nuget.codeplex.com/workitem/2990) - Ajoutez la propriété Version à la classe NetPortableProfile.
  13. [David Simner](https://www.codeplex.com/site/users/view/DavidSimner)
    • [#3460](https://nuget.codeplex.com/workitem/3460) - Correction du bogue NullReferenceException si requireApiKey = true, mais l’en-tête X-NUGET-APIKEY n’est pas présent
  14. [Michael Friis](https://www.codeplex.com/site/users/view/friism) (@friism)
    • [#3278](https://nuget.codeplex.com/workitem/3278) - Corrige le fichier cible NuGet.Build pour qu’il fonctionne correctement sur MonoDevelop
  15. [Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm) (@pranav_km)
    • Améliorer les performances des commandes Restore (rétablir) en augmentant la parallélisation

Fonctionnalités notables de la version

NuGet 2.7 introduit une nouvelle approche de la restauration de package et dépasse également un obstacle majeur : le consentement de restauration de package est désormais activé par défaut ! La combinaison de la nouvelle approche et du consentement implicite simplifiera considérablement les scénarios de restauration de package.

Avec NuGet versions 2.0, 2.1, 2.2, 2.5 et 2.6, les utilisateurs devaient autoriser explicitement NuGet à télécharger des packages manquants pendant la génération de la version. Si ce consentement n’avait pas été explicitement donné, les solutions qui avaient activé la restauration de package ne pouvaient pas être générées tant que l’utilisateur n’avait pas accordé son consentement.

À compter de NuGet 2.7, le consentement de restauration de package est activé par défaut tout en permettant aux utilisateurs de refuser explicitement la restauration de package si vous le souhaitez, à l’aide de la case à cocher dans les paramètres de NuGet dans Visual Studio. Cette modification du consentement implicite affecte NuGet dans les environnements suivants :

  • Visual Studio 2013 Preview (Aperçu)
  • Visual Studio 2012
  • Visual Studio 2010
  • Utilitaire de ligne de commande nuget.exe

Restauration de package automatique avec Visual Studio

À compter de NuGet 2.7, NuGet télécharge automatiquement les packages manquants pendant la génération de la version dans Visual Studio, même si la restauration de package n’a pas été explicitement activée pour la solution. Cette restauration automatique de package se produit dans Visual Studio lorsque vous générez un projet ou la solution, mais avant l’appel de MSBuild. Cela offre quelques avantages significatifs :

  1. Vous n’avez plus besoin d’utiliser le mouvement « Activer la restauration de package NuGet » sur votre solution
  2. Les projets n’ont pas besoin d’être modifiés et NuGet ne modifie pas votre projet pour garantir que la restauration des packages est activée
  3. Tous les packages NuGet, y compris ceux qui incluaient les importations MSBuild pour les fichiers de propriétés/fichiers cibles, seront restaurés avant que MSBuild soit appelé, ce qui garantit que ces propriétés/cibles sont correctement reconnues pendant la génération de la version

Pour utiliser la restauration automatique des packages dans Visual Studio, vous devez effectuer une seule (in)action :

  1. N’archivez pas votre dossier packages

Il existe plusieurs façons d’omettre votre dossier packages du contrôle de code source. Pour plus d’informations, consultez le sujet Packages et contrôle de code source.

Bien que tous les utilisateurs soient implicitement acceptés dans le consentement de restauration automatique des packages, vous pouvez facilement refuser via les paramètres de Gestionnaire de package dans Visual Studio.

Package Manager Settings

Restauration d’un package simplifié à partir de la ligne de commande.

NuGet 2.7 introduit une nouvelle fonctionnalité pour nuget.exe : nuget.exe restore

Cette nouvelle commande Restore (Rétablir) vous permet de restaurer facilement tous les packages d’une solution avec une seule commande, en acceptant un fichier ou un dossier de solution en tant qu’argument. En outre, cet argument est implicite lorsqu’il n’existe qu’une seule solution dans le dossier actif. Cela signifie le suivi de tout le travail à partir d’un dossier qui contient un seul fichier de solution (MySolution.sln) :

  1. nuget.exe restore MySolution.sln
  2. nuget.exe restore.
  3. nuget.exe restore

La commande Restore (Rétablir) ouvre le fichier solution et recherche tous les projets au sein de la solution. À partir de là, il va trouver les fichiers packages.config de chacun des projets et rétablir tous les packages trouvés. Il rétablit également les packages au niveau de la solution trouvés dans le fichier .nuget\packages.config. Vous trouverez plus d’informations sur la nouvelle commande Restore (Rétablir) dans la référence de ligne de commande.

Nouveau flux de travail de restauration de package

Nous sommes ravis de ces modifications apportées à la restauration de package, car elle introduit un nouveau flux de travail. Si vous souhaitez omettre vos packages du contrôle de code source, il vous suffit de ne pas valider le dossier packages. Les utilisateurs de Visual Studio qui ouvrent et créent la solution verront les packages automatiquement restaurés. Pour les versions de ligne de commande, invoquez simplement nuget.exe restore avant d’invoquer msbuild. Vous n’avez plus besoin de vous rappeler d’utiliser le mouvement « Activer la restauration de package NuGet » sur votre solution, et nous n’aurons plus besoin de modifier vos projets pour modifier la version. Cela génère également une expérience considérablement améliorée pour les packages qui incluent les importations MSBuild, en particulier pour les importations ajoutées via la fonctionnalité récente de NuGet pour importer automatiquement des fichiers de propriétés/de cibles à partir du dossier \build.

En plus du travail que nous avons fait nous-mêmes, nous travaillons également avec certains partenaires importants pour arrondir cette nouvelle approche. Nous n’avons pas de chronologies concrètes pour l’un de ces derniers, mais chaque partenaire est aussi enthousiaste que nous sur la nouvelle approche.

  • Team Foundation Service : ses membres travaillent à l’intégration de l’appel à nuget.exe restore dans les scénarios de génération par défaut.
  • Sites Web Windows Azure : ces partenaires s’efforcent de vous permettre d’envoyer (push) votre projet vers Azure et de faire appeler nuget.exe restore avant la création de votre site Web.
  • TeamCity : ces partenaires mettent à jour leur plug-in NuGet Installer pour TeamCity 8.x
  • AppHarbor : ces partenaires s’efforcent de vous permettre d’envoyer (push) votre référentiel vers AppHarbor et de faire appeler nuget.exe restore avant la génération de votre solution.

Avec chacun des partenaires ci-dessus, ils utilisent leur propre copie de nuget.exe et vous n’aurez pas besoin de transporter nuget.exe dans votre solution.

Problèmes connus

Il y avait deux problèmes connus liés à la restauration nuget.exe avec la version initiale de la version 2.7, mais ils ont été résolus le 9/6/2013 avec une mise à jour du package NuGet.CommandLine. Cette mise à jour est également disponible sur [NuGet 2.7 download page](https://nuget.codeplex.com/releases/view/107605) sur CodePlex. L’exécution de nuget.exe update -self sera mise à jour vers la dernière version.

Les corrections étaient les suivantes :

  1. [New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
  2. [New package restore doesn't work with Wix projects](https://nuget.codeplex.com/workitem/3598)

Il existe également un problème connu avec le nouveau flux de travail de restauration de package par lequel [Automatic Package Restore does not work for projects under a solution folder](https://nuget.codeplex.com/workitem/3625). Ce problème a été résolu dans NuGet 2.7.1.

Erreurs/avertissements de génération de reciblage et de mise à niveau de projet

Bien souvent après le reciblage ou la mise à niveau de votre projet, vous constatez que certains packages NuGet ne fonctionnent pas correctement. Malheureusement, il n’y a aucune indication de cela, et il n’y a pas de conseils sur la façon de le traiter. Avec NuGet 2.7, nous utilisons maintenant certains événements Visual Studio pour reconnaître quand vous avez reciblé ou mis à niveau votre projet d’une manière qui affecte vos packages NuGet installés.

Si nous détectons que l’un de vos packages a été affecté par le reciblage ou la mise à niveau, nous allons générer des erreurs de build immédiates pour vous informer. En plus de l’erreur de build immédiate, nous conservons également un indicateur requireReinstallation="true" dans votre fichier packages.config pour tous les packages affectés par le reciblage, et chaque version suivante dans Visual Studio génère des avertissements de build pour ces packages.

Bien que NuGet ne puisse pas effectuer d’action automatique pour réinstaller les packages affectés, nous espérons que cette indication et cet avertissement vous aideront à découvrir quand vous devrez réinstaller des packages. Nous travaillons également sur la documentation d’aide à la réinstallation de package vers laquelle ces messages d’erreur vous dirigent.

Valeurs par défaut de la configuration NuGet

De nombreuses sociétés utilisent NuGet en interne, mais ont eu du mal à amener leurs développeurs à utiliser des sources de package internes au lieu de nuget.org. NuGet 2.7 introduit une fonctionnalité de configuration par défaut qui permet de spécifier les paramètres par défaut à l’échelle de l’ordinateur pour ce qui suit :

  1. Sources de package activées
  2. Sources de package inscrites mais désactivées
  3. Source push nuget.exe par défaut

Chacun de ces éléments peut maintenant être configuré dans un fichier situé à l’adresse %ProgramData%\NuGet\NuGetDefaults.Config. Si ce fichier config spécifie des sources de package, la source de package par défaut nuget.org ne sera pas inscrite automatiquement, et celles dans NuGetDefaults.Config seront inscrites à la place.

Bien qu’il ne soit pas nécessaire d’utiliser cette fonctionnalité, nous nous attendons à ce que les sociétés déploient des fichiers NuGetDefaults.Config à l’aide de la stratégie de groupe.

Notez que cette fonctionnalité n’entraîne jamais la suppression d’une source de package des paramètres NuGet d’un développeur. Cela signifie que si le développeur a déjà utilisé NuGet, et donc, que la source du package nuget.org est inscrite, celle-ci ne sera pas supprimée après la création d’un fichier NuGetDefaults.Config.

Pour plus d’informations sur la configuration des flux NuGet, consultez Valeurs par défaut de la configuration de NuGet.

Renommage de la source de package par défaut

NuGet a toujours inscrit une source de package par défaut appelée « Source de package officielle NuGet » qui pointe vers nuget.org. Ce nom était détaillé et il ne spécifiait pas non plus où il pointait réellement. Pour résoudre ces deux problèmes, nous avons renommé cette source de package tout simplement « nuget.org » dans l’IU. L’URL de la source du package a également été modifiée pour inclure le préfixe « www ». Après avoir utilisé NuGet 2.7, votre « source de package officielle NuGet » existante est automatiquement mise à jour sur « nuget.org » comme nom et « https://www.nuget.org/api/v2/ » comme URL.

Améliorations des performances

Nous avons apporté une amélioration des performances dans la version 2.7, ce qui permettra une empreinte mémoire plus petite, moins d’utilisation du disque et une installation plus rapide du package. Nous avons également effectué des requêtes plus intelligentes sur des flux basés sur OData qui réduisent la charge utile globale.

Nouvelles API d’extensibilité

Nous avons ajouté de nouvelles API à nos services d’extensibilité pour remplir l’écart des fonctionnalités manquantes dans les versions précédentes.

IVsPackageInstallerServices

// Checks if a NuGet package with the specified Id and version is installed in the specified project.
bool IsPackageInstalledEx(Project project, string id, string versionString);

// Get the list of NuGet packages installed in the specified project.
IEnumerable<IVsPackageMetadata> GetInstalledPackages(Project project);

IVsPackageInstaller

// Installs one or more packages that exist on disk in a folder defined in the registry.
void InstallPackagesFromRegistryRepository(string keyName, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

// Installs one or more packages that are embedded in a Visual Studio Extension Package.
void InstallPackagesFromVSExtensionRepository(string extensionId, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

Dépendances de développement uniquement

Cette fonctionnalité a bénéficié de la contribution d’Adam Ralph et permet aux auteurs de packages de déclarer des dépendances qui n’ont été utilisées qu’au moment du développement et qui ne nécessitent pas de dépendances de package. En ajoutant un attribut developmentDependency="true" à un package dans packages.config, nuget.exe pack ne va plus inclure ce package en tant que dépendance.

Suppression du support de Visual Studio 2010 Express pour Windows Phone

Le nouveau modèle de restauration de package dans la version 2.7 est implémenté par un nouveau VSPackage différent du VSPackage NuGet principal. En raison d’un problème technique, ce nouveau VSPackage ne fonctionne pas correctement dans la référence SKU Visual Studio 2010 Express pour Windows Phone (téléphone Windows), car nous partageons la même base de code avec d’autres références SKU Visual Studio prises en charge. Par conséquent, à partir de NuGet 2.7, nous excluons le support de Visual Studio 2010 Express pour Windows Phone (téléphone Windows) à partir de l’extension publiée. Le support de Visual Studio 2010 Express pour le Web est toujours inclus dans l’extension principale publiée dans la galerie d’extensions Visual Studio.

Étant donné que nous ne sommes pas sûrs du nombre de développeurs qui utilisent toujours NuGet dans cette version/édition de Visual Studio, nous publions une extension Visual Studio distincte spécifiquement pour ces utilisateurs et la publiant sur CodePlex (plutôt que dans la galerie d’extensions Visual Studio). Nous ne prévoyons pas de continuer à maintenir cette extension, mais si cela vous affecte, veuillez nous le faire savoir en signalant un problème sur CodePlex.

Pour télécharger le Gestionnaire de package NuGet (pour Visual Studio 2010 Express pour Windows Phone), visitez la page [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605).

Correctifs de bogues

Outre ces fonctionnalités, cette version de NuGet inclut également de nombreux autres correctifs de bogues. Un total de 97 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.7, veuillez consulter [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all).