Notes de publication de NuGet 2.1

Notes de publication de NuGet 2.0 | Notes de publication de NuGet 2.2

NuGet 2.1 a été publié le 4 octobre 2012.

Config hiérarchique de NuGet

NuGet 2.1 vous offre une plus grande flexibilité pour contrôler les paramètres NuGet en marchant de manière récursive dans la structure des dossiers à la recherche NuGet.Config de fichiers, puis en créant la configuration à partir de l’ensemble de tous les fichiers trouvés. Par exemple, considérez le scénario dans lequel une équipe dispose d’un référentiel de package interne pour les builds CI d’autres dépendances internes. La structure de dossiers d’un projet individuel peut ressembler à ce qui suit :

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

En outre, si la restauration de package est activée pour la solution, le dossier suivant existe également :

C:\myteam\solution1\.nuget

Pour que le référentiel de packages interne de l’équipe soit disponible pour tous les projets sur lesquels l’équipe travaille, tout en le rendant indisponible pour chaque projet sur la machine, nous pouvons créer un nouveau fichier Nuget.Config et le placer dans le dossier c:\myteam. Il n’existe aucun moyen de spécifier un dossier de packages distinct pour chaque projet.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

Nous pouvons maintenant voir que la source a été ajoutée en exécutant la commande «nuget.exe sources » à partir de n’importe quel dossier sous c :\myteam, comme indiqué ci-dessous :

NuGet.Config les fichiers sont recherchés dans l’ordre suivant :

1. .nuget\Nuget.Config
2. Traversée récursive du dossier du projet vers la racine
3. Global Nuget.Config (%appdata%\NuGet\Nuget.Config)

Les configurations sont appliquées dans l’ordre inverse, ce qui signifie que, en fonction de l’ordre ci-dessus, le fichier Nuget.Config global est appliqué en premier, suivi des fichiers Nuget.Config découverts de la racine au dossier du projet, suivis par .nuget\Nuget.Config. Cela est particulièrement important si vous utilisez l’élément <clear/> pour supprimer un ensemble d’éléments de la configuration.

Spécifier l’emplacement du dossier « packages »

Par le passé, NuGet a géré les packages d’une solution à partir d’un dossier « packages » connu sous le dossier racine de la solution. Pour les équipes de développement qui ont de nombreuses solutions différentes sur lesquelles les packages NuGet sont installés, cela peut entraîner l’installation du même package dans de nombreux endroits différents sur le système de fichiers.

NuGet 2.1 fournit un contrôle plus précis sur l’emplacement du dossier packages via l’élément repositoryPath du NuGet.Config fichier. En se basant sur l’exemple précédent de prise en charge hiérarchique de Nuget.Config, supposons que nous souhaitons que tous les projets sous C :\myteam\ partagent le même dossier de packages. Pour ce faire, ajoutez simplement l’entrée suivante à c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

Dans cet exemple, le fichier partagé spécifie un dossier de packages partagés Nuget.Config pour chaque projet créé sous C :\myteam, quelle que soit la profondeur. Notez que si vous disposez d’un dossier de packages existant sous la racine de votre solution, vous devez le supprimer avant que NuGet place les packages dans le nouvel emplacement.

Prise en charge des bibliothèques portables

Les bibliothèques portables sont une fonctionnalité introduite pour la première fois avec .NET 4 qui vous permet de créer des assemblys qui peuvent fonctionner sans modification sur différentes plateformes Microsoft, de versions de the.NET Framework à Silverlight vers Windows Phone et même Xbox 360 (bien qu’à ce stade, NuGet ne prend pas en charge la cible de bibliothèque portable Xbox). En étendant les conventions de package pour les versions et les profils d’infrastructure, NuGet 2.1 prend désormais en charge les bibliothèques portables en vous permettant de créer des packages qui ont des dossiers cibles lib d’infrastructure et de profil composés.

Par exemple, considérez les plateformes cibles disponibles de la bibliothèque de classes portables suivantes.

Une fois la bibliothèque générée et la commande nuget.exe pack MyPortableProject.csproj exécutée, la nouvelle structure de dossiers de package de bibliothèque portable est visible en examinant le contenu du package NuGet généré.

Comme vous pouvez le voir, la convention de nom de dossier de bibliothèque portable suit le modèle « portable-{framework 1}+{framework n} » où les identificateurs de framework suivent les conventions de nom et de version de l’infrastructure existantes. Une exception aux conventions de nom et de version se trouve dans l’identificateur d’infrastructure utilisé pour Windows Phone. Ce moniker doit utiliser le nom du framework « wp » (wp7, wp71 ou wp8). L’utilisation de « silverlight-wp7 », par exemple, entraîne une erreur.

Lors de l’installation du package créé à partir de cette structure de dossiers, NuGet peut désormais appliquer son framework et ses règles de profil à plusieurs cibles, comme spécifié dans le nom du dossier. Derrière les règles de correspondance de NuGet, il s’agit du principe selon lequel les cibles « plus spécifiques » sont prioritaires sur les cibles « moins spécifiques ». Cela signifie que les monikers ciblant une plateforme spécifique seront toujours préférés aux monikers portables s’ils sont tous les deux compatibles avec un projet. En outre, si plusieurs cibles portables sont compatibles avec un projet, NuGet préfère celle où l’ensemble de plateformes prises en charge est « le plus proche » du projet référençant le package.

Ciblage de projets Windows 8 et Windows Phone 8

Outre l’ajout de la prise en charge du ciblage de projets de bibliothèque portable, NuGet 2.1 fournit de nouveaux monikers de framework pour les projets Windows 8 Store et Windows Phone 8, ainsi que certains nouveaux monikers généraux pour les projets Windows Store et Windows Phone qui seront plus faciles à gérer sur les futures versions des plateformes respectives.

Pour les applications du Windows 8 Store, les identificateurs se présentent comme suit :

Amélioration de la recherche dans la boîte de dialogue Gestionnaire de package

Au cours des dernières itérations, les modifications ont été introduites dans la galerie NuGet qui a considérablement amélioré la vitesse et la pertinence des recherches de package. Toutefois, ces améliorations étaient limitées au site web nuget.org. NuGet 2.1 rend l’expérience de recherche améliorée disponible via la boîte de dialogue gestionnaire de package NuGet. Par exemple, imaginez que vous vouliez trouver le package Windows Azure Caching Preview. Une requête de recherche raisonnable pour ce package peut être « Cache Azure ». Dans les versions précédentes de la boîte de dialogue gestionnaire de package, le package souhaité n’est même pas répertorié sur la première page des résultats. Toutefois, dans NuGet 2.1, le package souhaité apparaît désormais en haut des résultats de la recherche.

Forcer la mise à jour du package

Avant NuGet 2.1, NuGet ignore la mise à jour d’un package lorsqu’il n’existe pas de numéro de version élevé. Cela a introduit des frictions pour certains scénarios, en particulier dans le cas de scénarios de build ou d'intégration continue où l’équipe ne voulait pas incrémenter le numéro de version du paquet avec chaque build. Le comportement souhaité était de forcer une mise à jour dans tous les cas. NuGet 2.1 traite cela avec l’indicateur « réinstaller ». Par exemple, les versions précédentes de NuGet entraînent les opérations suivantes lors de la tentative de mise à jour d’un package qui n’avait pas de version de package plus récente :

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

Avec l'option de réinstallation, le paquet sera mis à jour, peu importe s'il existe une version plus récente.

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

Un autre scénario où l’indicateur de réinstallation s’avère bénéfique est celui de la réorientation du framework. Lors de la modification de l’infrastructure cible d’un projet (par exemple, de .NET 4 à .NET 4.5), Update-Package -Reinstall pouvez mettre à jour les références aux assemblys appropriés pour tous les packages NuGet installés dans le projet.

Modifier des sources de package dans Visual Studio

Dans les versions précédentes de NuGet, la mise à jour d’une source de package à partir de la boîte de dialogue d’options De Visual Studio nécessite la suppression et la réinitulation de la source du package. NuGet 2.1 améliore ce flux de travail en prenant en charge la mise à jour en tant que fonction de première classe de l’interface utilisateur de configuration.

Les correctifs de bogues

NuGet 2.1 inclut de nombreux correctifs de bogues. 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=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0).