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 contributions significatives à NuGet 2.7 :

[Mike Roth](http://www.codeplex.com/site/users/view/mxrss) (@mxrss)
- Afficher l’URL de licence lors de l'affichage des paquets et que la verbosité est en mode détaillé.
[Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
- [#1956](http://nuget.codeplex.com/workitem/1956) - Ajouter l’attribut developmentDependency à et l’utiliser packages.config dans la commande pack pour inclure uniquement les packages d’exécution
[Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael) (@tkrafael)
- Évitez les clés de Propriétés dupliquées dans la commande pack de nuget.exe.
[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.
[Slava Trenogin](http://www.codeplex.com/site/users/view/derigel) (@derigel)
- [#3217](http://nuget.codeplex.com/workitem/3217) - Correction de la boîte de dialogue NuGet montrant les mises à jour sous l’onglet incorrect
- Correction : Project.TargetFramework peut être null dans ProjectManager
- [#3248](http://nuget.codeplex.com/workitem/3248) - Correction de SharedPackageRepository : FindPackage/FindPackagesById échouera avec un packageId inexistant
[Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG) (@kevfromireland)
- [#3234](http://nuget.codeplex.com/workitem/3234) - Activer la prise en charge du projet Nomad
[Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie) (@corinblaikie)
- [#3252](http://nuget.codeplex.com/workitem/3252) - Correction de la commande Push qui échoue avec un code de sortie 0 lorsque le fichier n'existe pas.
[Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
- [#3226](http://nuget.codeplex.com/workitem/3226) - Correction d’un bogue avec Add-BindingRedirect commande lorsqu’un projet fait référence à un projet de base de données.
[Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos) (@bajtos)
- [#2891](http://nuget.codeplex.com/workitem/2891) - Correction du bogue de l'analyse nuget.pack qui interprétait le caractère générique dans l'attribut « exclude » de manière incorrecte.
[Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981) (@zippy1981)
- [#3307](http://nuget.codeplex.com/workitem/3307) - Correction d'un bogue NuGet.targets ne passe pas $(Platform) à nuget.exe lors de la restauration des paquets.
[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 avec une casse différente, provoquant finalement le message d’exception « Item already exists » (Élément déjà existant).
[Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino) (@kzu)
- [#2990](http://nuget.codeplex.com/workitem/2990) - Ajouter la propriété Version à la classe NetPortableProfile.
[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
[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
[Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm) (@pranav_km)
- Améliorer les performances des commandes Restore en augmentant la parallélisation

Fonctionnalités notables dans 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 simplifie 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 doivent autoriser explicitement NuGet à télécharger des packages manquants pendant la build. Si ce consentement n’avait pas été explicitement donné, les solutions qui avaient activé la restauration de package échoueraient à être construites 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, en utilisant 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
Visual Studio 2012
Visual Studio 2010
utilitaire de ligne de commande nuget.exe

Restauration automatique des packages dans Visual Studio

À compter de NuGet 2.7, NuGet télécharge automatiquement les packages manquants pendant la génération 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 :

Vous n’avez plus besoin d’utiliser le mouvement « Activer la restauration de package NuGet » sur votre solution
Les projets n’ont pas besoin d’être modifiés et NuGet n’apporte pas de modifications à votre projet pour vous assurer que la restauration des packages est activée
Tous les packages NuGet, y compris ceux qui incluaient les importations MSBuild pour les fichiers props/targets, 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

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

Ne pas archiver votre packages dossier

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

Bien que tous les utilisateurs soient implicitement inscrits au consentement pour la restauration automatique des packages, vous pouvez facilement refuser cette option via les paramètres du Gestionnaire de packages dans Visual Studio.

Paramètres du Gestionnaire de package

Restauration simplifiée du package à partir de l'Command-Line

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

Cette nouvelle commande Restore 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 que tout ce qui suit fonctionne depuis un dossier contenant un fichier solution unique (MySolution.sln) :

nuget.exe restore MySolution.sln
nuget.exe restauration .
nuget.exe restaurer

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

Le nouveau processus 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 packages dossier. Les utilisateurs de Visual Studio qui ouvrent et créent la solution verront les packages automatiquement restaurés. Pour les compilations en ligne de commande, appelez simplement nuget.exe restore avant d’appeler 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 build. Cela génère également une expérience beaucoup 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 props/targets à 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 encore de chronologies concrètes pour l’un de ces éléments, mais chaque partenaire est aussi heureux que nous sommes au sujet de la nouvelle approche.

Team Foundation Service : ils travaillent à intégrer l’appel vers nuget.exe restore dans les scénarios de construction par défaut.
Sites web Windows Azure : ils fonctionnent pour vous permettre d’envoyer (push) votre projet vers Azure et d’avoir nuget.exe restore appelé avant la création de votre site web.
TeamCity - Ils mettent à jour leur plug-in NuGet Installer pour TeamCity 8.x
AppHarbor : ils travaillent pour permettre de transférer votre dépôt vers AppHarbor et d’avoir nuget.exe restore appelé avant la compilation de votre solution.

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

Problèmes connus

Il existe 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 6/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) CodePlex. Pour mettre à jour vers la dernière version, exécutez nuget.exe update -self.

Les corrections étaient les suivantes :

[New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
[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 processus de restauration de package qui se manifeste par [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 lors du reciblage et de la mise à niveau du projet

Plusieurs fois après reciblage ou mise à niveau de votre projet, vous constatez que certains packages NuGet ne fonctionnent pas correctement. Malheureusement, il n’y a aucune indication de cela, puis 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 paquets a été affecté par le reciblage ou la mise à niveau, nous générerons des erreurs de build immédiates pour vous en informer. En plus de l’erreur de compilation 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 compilation suivante dans Visual Studio génère des avertissements de compilation pour ces packages.

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

Valeurs par défaut de la configuration NuGet

De nombreuses entreprises utilisent NuGet en interne, mais ont eu du mal à guider 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 aux paramètres par défaut à l’échelle de l’ordinateur d’être spécifiés pour :

Sources de package activées
Sources de package inscrites, mais désactivées
Source d'envoi par défaut de nuget.exe

Chacun de ces éléments peut maintenant être configuré dans un fichier situé à l’adresse %ProgramData%\NuGet\NuGetDefaults.Config. Si ce fichier de configuration spécifie des sources de package, la source de package par défaut nuget.org ne sera pas inscrite automatiquement, et celles spécifiées 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 entreprises déploient des NuGetDefaults.Config fichiers à 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 a donc la source de package nuget.org inscrite, elle ne sera pas supprimée après la création d’un NuGetDefaults.Config fichier.

Pour plus d’informations sur cette fonctionnalité, consultez Les valeurs par défaut de configuration NuGet .

Renommage de la source de paquet 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 n’a pas non plus spécifié où il pointait réellement. Pour résoudre ces deux problèmes, nous avons renommé cette source de package en « nuget.org » simplement dans l’interface utilisateur. 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 de réduire l’encombrement mémoire, moins d’utilisation du disque et d’installer plus rapidement les packages. Nous avons également effectué des requêtes plus intelligentes sur des flux OData qui réduisent la charge utile globale.

Nouvelles API d’extensibilité

Nous avons ajouté de nouvelles API à nos services d’extensibilité pour combler 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 uniquement pour le développement

Cette fonctionnalité a été contribuée par 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 n'inclura plus ce package comme dépendance.

Suppression de la prise en charge 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 qui diffère du NuGet VSPackage 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 , car nous partageons la même base de code avec d’autres références SKU Visual Studio prises en charge. Par conséquent, nous retirons la prise en charge de Visual Studio 2010 Express pour Windows Phone de l'extension publiée, à partir de NuGet 2.7. La prise en charge de Visual Studio 2010 Express for Web est toujours incluse 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 plaçant un problème sur CodePlex.

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

Les correctifs de bogues

Outre ces fonctionnalités, cette version de NuGet inclut également de nombreux autres correctifs de bogues. 97 problèmes totaux ont été résolus dans la version. Pour obtenir la liste complète des éléments de travail corrigés dans NuGet 2.7, consultez [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all).

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-10-31