Notes de publication de NuGet 1.8

Notes de publication de NuGet 1.7 | Notes de publication de NuGet 2.0

NuGet 1.8 a été publié le 23 mai 2012.

Problème d’installation connu

Si vous exécutez VS 2010 SP1, vous risquez d’exécuter une erreur d’installation lors de la tentative de mise à niveau de NuGet si vous avez installé une version antérieure.

La solution de contournement consiste simplement à désinstaller NuGet, puis à l’installer à partir de la galerie d’extensions VS. Voir https://support.microsoft.com/kb/2581019 pour plus d’informations, ou accédez directement au correctif logiciel VS.

Remarque : Si Visual Studio ne vous permettra pas de désinstaller l’extension (le bouton Désinstaller est désactivé), vous devrez probablement redémarrer Visual Studio à l’aide de « Exécuter en tant qu’administrateur ».

NuGet 1.8 Incompatible avec Windows XP, correctif logiciel publié

Peu après la publication de NuGet 1.8, nous avons appris qu’un changement de chiffrement dans la version 1.8 a causé des problèmes pour les utilisateurs sur Windows XP.

Nous avons depuis publié un correctif logiciel qui résout ce problème. En mettant à jour NuGet via la galerie d’extensions Visual Studio, vous recevez ce correctif logiciel.

Fonctionnalités

Packages satellites pour les ressources localisées

NuGet 1.8 prend désormais en charge la possibilité de créer des packages distincts pour les ressources localisées, comme les fonctionnalités d’assembly satellite du .NET Framework. Un package satellite est créé de la même façon que tout autre package NuGet avec l’ajout de quelques conventions :

• L’ID de package satellite et le nom de fichier doivent inclure un suffixe qui correspond à l’une des chaînes de culture standard utilisées par le .NET Framework.
• Dans son .nuspec fichier, le package satellite doit définir un élément de langage avec la même chaîne de culture que celle utilisée dans l’ID
• Le package satellite doit définir une dépendance dans son .nuspec fichier à son package principal, qui est simplement le package avec le même ID moins le suffixe de langue. Le package principal doit être disponible dans le référentiel pour une installation réussie.

Pour installer un package avec des ressources localisées, un développeur sélectionne explicitement le package localisé dans le référentiel. À l’heure actuelle, la galerie NuGet ne donne aucun traitement spécial aux packages satellites.

Étant donné que le package satellite répertorie une dépendance à son package principal, les packages satellite et core sont extraits dans le dossier des packages NuGet et installés.

En outre, lors de l’installation du package satellite, NuGet reconnaît également la convention de nommage via chaîne de culture, puis copie l’assembly de ressources localisé dans le sous-dossier approprié du package principal afin qu’il puisse être récupéré par le .NET Framework.

Un bogue existant à noter avec les packages satellites est que NuGet ne copie pas les ressources localisées dans le bin dossier des projets de site Web. Ce problème sera résolu dans la prochaine version de NuGet.

Pour obtenir un exemple complet illustrant comment créer et utiliser des packages satellites, consultez https://github.com/NuGet/SatellitePackageSample.

Consentement de restauration de package

Dans NuGet 1.8, nous avons posé les bases de la prise en charge d’une contrainte importante sur la restauration des packages pour protéger la confidentialité des utilisateurs. Cette contrainte requiert que les développeurs qui construisent des projets et des solutions utilisant la restauration de packages consentent explicitement à ce que la restauration de packages puisse aller en ligne afin de télécharger des packages à partir de sources de packages configurées.

Il existe 2 façons de fournir ce consentement. Vous trouverez le premier dans la boîte de dialogue de configuration du gestionnaire de package, comme indiqué ci-dessous. Cette méthode est principalement destinée aux machines de développement.

La deuxième méthode consiste à définir la variable d’environnement « EnableNuGetPackageRestore » sur la valeur « true ». Cette méthode est destinée aux ordinateurs sans assistance tels que les serveurs CI ou build.

Comme indiqué ci-dessus, nous n’avons posé que les bases de cette fonctionnalité dans NuGet 1.8. En pratique, cela signifie que même si nous avons ajouté toute la logique pour activer la fonctionnalité, elle n’est pas actuellement appliquée dans cette version. Toutefois, elle sera activée dans la prochaine version de NuGet. Nous voulions donc vous en informer dès que possible afin que vous puissiez configurer vos environnements de manière appropriée et ne pas être impactée lorsque nous commençons à appliquer la contrainte de consentement.

Pour plus d’informations, consultez le billet de blog de l’équipe sur cette fonctionnalité.

Améliorations des performances : nuget.exe

En modifiant la commande d’installation pour télécharger et installer des packages en parallèle, NuGet 1.8 apporte des améliorations spectaculaires des performances à nuget.exe et par restauration de package d’extension. Les tests de haut niveau montrent que les performances d’installation de 6 packages dans un projet s’améliorent d’environ 35% dans NuGet 1.8. L’augmentation du nombre de packages à 25 montre un gain de performances d’environ 60%.

Les correctifs de bogues

NuGet 1.8 inclut quelques correctifs de bogues avec une attention particulière sur le flux de travail de restauration de package et de console du gestionnaire de package, en particulier en ce qui concerne le consentement de restauration de package et l’intégration de Windows 8 Express. Pour obtenir la liste complète des éléments de travail corrigés dans NuGet 1.8, consultez le [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Closed&type=All&priority=All&release=NuGet%201.8&assignedTo=All&component=All&sortField=Votes&sortDirection=Descending&page=0) fichier.