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.
NuGet 2.1 vous offre une plus grande flexibilité pour contrôler les paramètres NuGet en parcourant de manière récursive la structure des dossiers à la recherche de fichiers NuGet.Config
, puis en créant la configuration à partir de l’ensemble de tous les fichiers trouvés. Par exemple, envisagez le scénario dans lequel une équipe dispose d’un référentiel de packages internes pour les builds CI d’autres dépendances internes. La structure de dossiers pour un projet individuel peut ressembler à la structure ci-après :
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 internes de l’équipe soit disponible pour tous les projets sur lesquels l’équipe travaille, sans pour autant le rendre disponible à tous les projets sur l’ordinateur, nous pouvons créer un nouveau fichier Nuget.Config et le placer dans le dossier c:\myteam. Il n’y a aucun moyen de créer un dossier de paquets spécifique 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 :
Les fichiers NuGet.Config
sont recherchés dans l’ordre suivant :
.nuget\Nuget.Config
- Parcours récursif du dossier du projet à la racine
Nuget.Config
global (%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.
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 fichier NuGet.Config
. 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 Nuget.Config
partagé spécifie un dossier de packages partagés 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.
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, des versions de the.NET Framework à Silverlight jusqu’à 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 aux 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 lib
cibles d’infrastructures et de profils composés.
À titre d’exemple, prenons les plateformes cibles disponibles de la bibliothèque de classes portables suivantes.
Une fois la bibliothèque créé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 du 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’identifiant d’infrastructure utilisé pour Windows Phone. Ce moniker doit utiliser le nom de l’infrastructure « wp » (wp7, wp71 ou wp8). Par exemple, l’utilisation de « silverlight-wp7 » provoquera une erreur.
Lors de l’installation du package créé à partir de cette structure de dossiers, NuGet peut désormais appliquer son infrastructure et ses règles de profil à plusieurs cibles, comme spécifié dans le nom du dossier. Les règles de correspondance de NuGet reposent sur le 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èrera celle où l’ensemble de plateformes prises en charge est « le plus proche » du projet référençant le package.
Outre l’ajout de la prise en charge du ciblage de projets de bibliothèque portable, NuGet 2.1 fournit de nouveaux monikers d’infrastructure 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 dans les futures versions des plateformes respectives.
Pour les applications Windows 8 Store, les identifiants se présentent comme suit :
NuGet 2.0 et versions antérieures | NuGet 2.1 |
---|---|
winRT45, . NETCore45 | Windows, Windows8, win, win8 |
Pour les projets Windows Phone, les identifiants se présentent comme suit :
Phone OS | NuGet 2.0 et versions antérieures | NuGet 2.1 |
---|---|---|
Windows Phone 7 | silverlight3-wp | wp, wp7, WindowsPhone, WindowsPhone7 |
Windows Phone 7.5 (Mango) | silverlight4-wp71 | wp71, WindowsPhone71 |
Windows Phone 8 | (non pris en charge) | wp8, WindowsPhone8 |
Dans toutes les modifications ci-dessus, les anciens noms d’infrastructure continueront d’être entièrement pris en charge par NuGet 2.1. À l’avenir, les nouveaux noms doivent être utilisés, car ils seront plus stables dans les futures versions des plateformes respectives. Les nouveaux noms ne seront *pas* pris en charge dans les versions de NuGet antérieures à la version 2.1. Planifiez donc en conséquence le moment où effectuer le changement.
Au cours des dernières itérations, les modifications introduites dans la galerie NuGet ont 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 cette amélioration de l’expérience de recherche disponible via la Boîte de dialogue du 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 « Azure Cache ». Dans les versions précédentes de la Boîte de dialogue du 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 tête des résultats de la recherche.
Avant NuGet 2.1, NuGet ne mettait pas à jour un package lorsque le numéro de version n’était pas élevé. Cela a introduit des frictions dans certains scénarios, en particulier dans le cas de scénarios CI ou de build où l’équipe ne voulait pas incrémenter le numéro de version du package à chaque build. Le comportement souhaité était de forcer une mise à jour sans tenir compte de la situation. NuGet 2.1 aborde cela avec l’indicateur de « réinstallation ». Par exemple, les versions précédentes de NuGet entraînaient les résultats suivants 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’indicateur de réinstallation, le package est mis à jour, qu’il existe ou non 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 du reciblage de l’infrastructure. Lors de la modification de l’infrastructure cible d’un projet (par exemple, de .NET 4 à .NET 4.5), Update-Package -Reinstall peut mettre à jour les références aux assemblys appropriés pour tous les packages NuGet installés dans le projet.
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 le rajout 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.
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, veuillez consulter [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)
.