Partager via

Notes de publication de NuGet 2.0

Notes de publication de NuGet 1.8 | Notes de publication de NuGet 2.1

NuGet 2.0 a été publié le 19 juin 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 ».

Comme décrit dans cet article sur le consentement de restauration de package, NuGet 2.0 exigera désormais que le consentement soit donné pour permettre à la restauration de package de se connecter à Internet et d'y télécharger des packages. Vérifiez que vous avez fourni le consentement via la boîte de dialogue de configuration du gestionnaire de package ou la variable d’environnement EnableNuGetPackageRestore.

Regrouper les dépendances par frameworks cibles

À compter de la version 2.0, les dépendances de package peuvent varier en fonction du profil d’infrastructure du projet cible. Cette opération s’effectue à l’aide d’un schéma mis à jour .nuspec . L’élément <dependencies> peut maintenant contenir un ensemble d’éléments <group> . Chaque groupe contient zéro ou plusieurs <dependency> éléments et un targetFramework attribut. Toutes les dépendances à l’intérieur d’un groupe sont installées ensemble si l’infrastructure cible est compatible avec le profil de l’infrastructure de projet cible. Par exemple:

<dependencies>
    <group>
        <dependency id="RouteMagic" version="1.1.0" />
    </group>

    <group targetFramework="net40">
        <dependency id="jQuery" />
        <dependency id="WebActivator" />
    </group>

    <group targetFramework="sl30">
    </group>
</dependencies>

Notez qu’un groupe peut contenir zéro dépendance. Dans l’exemple ci-dessus, si le package est installé dans un projet qui cible Silverlight 3.0 ou version ultérieure, aucune dépendance n’est installée. Si le package est installé dans un projet qui cible .NET 4.0 ou version ultérieure, deux dépendances, jQuery et WebActivator, sont installées. Si le package est installé dans un projet qui cible une version antérieure de ces 2 frameworks, ou toute autre infrastructure, RouteMagic 1.1.0 est installé. Il n’y a pas d’héritage entre les groupes. Si l’infrastructure cible d’un projet correspond à l’attribut targetFramework d’un groupe, seules les dépendances au sein de ce groupe sont installées.

Un package peut spécifier des dépendances de package dans l’un des deux formats suivants : l’ancien format d’une liste plate d’éléments ou de <dependency> groupes. Si le <group> format est utilisé, le package ne peut pas être installé dans les versions de NuGet antérieures à la version 2.0.

Notez que le mélange des deux formats n’est pas autorisé. Par exemple, l’extrait de code suivant n’est pas valide et sera rejeté par NuGet.

<dependencies>
    <dependency id="jQuery" />
    <dependency id="WebActivator" />

    <group>
        <dependency id="RouteMagic" version="1.1.0" />
    </group>
</dependencies>

Regroupement de fichiers de contenu et de scripts PowerShell par framework cible

Outre les références d’assembly, les fichiers de contenu et les scripts PowerShell peuvent également être regroupés par infrastructure cible. La même structure de dossiers trouvée dans le dossier lib pour spécifier l’infrastructure cible peut désormais être appliquée de la même façon aux dossiers content et tools. Par exemple:

\content
    \net11
        \MyContent.txt
    \net20
        \MyContent20.txt
    \net40
    \sl40
        \MySilverlightContent.html

\tools
    \init.ps1
    \net40
        \install.ps1
        \uninstall.ps1
    \sl40
        \install.ps1
        \uninstall.ps1

Remarque : Étant donné qu’elle init.ps1 est exécutée au niveau de la solution et qu’elle ne dépend pas d’un projet individuel, elle doit être placée directement sous le tools dossier. Si elle est placée dans un dossier spécifique au framework, elle est ignorée.

En outre, une nouvelle fonctionnalité dans NuGet 2.0 est qu’un dossier d’infrastructure peut être vide, auquel cas NuGet n’ajoute pas de références d’assembly, ajoute des fichiers de contenu ou exécute des scripts PowerShell pour la version particulière de l’infrastructure. Dans l’exemple ci-dessus, le dossier content\net40 est vide.

Amélioration des performances de complétion des onglets

La fonctionnalité de complétion par tabulation dans la console du Gestionnaire de packages de NuGet a été mise à jour pour améliorer considérablement les performances. Il y aura beaucoup moins de retard à partir du moment où la touche Tab est enfoncée jusqu’à ce que la liste déroulante suggestion apparaisse.

Les correctifs de bogues

NuGet 2.0 inclut de nombreux correctifs de bogues en mettant l’accent sur le consentement et les performances de restauration de package. Pour obtenir la liste complète des éléments de travail corrigés dans NuGet 2.0, consultez le [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Closed&type=All&priority=All&release=NuGet%202.0&assignedTo=All&component=All&sortField=Votes&sortDirection=Descending&page=0).

  • Last updated on