TESTER FACILEMENT EN LOCAL LA CRÉATION D’UN PACKAGE NUGET
L’objectif de cet article est de parler de la création de package Nuget et plus particulièrement de comment il est possible, facilement et en local, de tester que votre nouveau package fonctionne correctement.
Cas pratique
Nous avons un certain nombre de solutions qui contiennent des projets librairies que nous partageons sous forme de package Nuget. La plupart du temps j’ai pu remarquer que pour effectuer des évolutions sur ces projets, les modifications étaient poussées jusqu’à l’usine de build et notre dépôt Nuget privé. C’est ensuite lors de l’utilisation du package mis à jour que l’on avait tendance à se rendre compte de certains oublis.
Suite à ce constat, j’ai trouvé intéressant d’expliquer comment il est possible de tester en local un package Nuget.
Packaging
Nous gérons la création de nos packages grâce aux fichiers .nuspec que nous écrivons manuellement. D’autres options sont possibles, n’hésitez pas à consulter la documentation officielle à ce sujet.
Fichier .nuspec et variables
Voici le genre de fichier .nuspec que nous utilisons :
<?xml version="1.0" encoding="utf-8"?><package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"><metadata><id>Yuc.Helper.Client</id><version>1.0.0</version><authors>Core Team - Younited Credit</authors><requireLicenseAcceptance>false</requireLicenseAcceptance><description>Helper Client</description><dependencies><dependency id="System.ComponentModel.Annotations" version="4.4.1" /></dependencies></metadata><files><file src="Yuc.Helper.Client\bin\$configuration$\netstandard2.0\Yuc.Helper.Client.dll" target="lib\netstandard2.0" /><file src="Yuc.Helper.Client\bin\$configuration$\netstandard2.0\Yuc.Helper.Client.pdb" target="lib\netstandard2.0" /><file src="Yuc.Helper.Client\bin\$configuration$\netstandard2.0\Yuc.Helper.Client.xml" target="lib\netstandard2.0" /><file src="Yuc.Helper.Client\bin\$configuration$\netstandard2.0\Yuc.Helper.Dto.dll" target="lib\netstandard2.0" /><file src="Yuc.Helper.Client\bin\$configuration$\netstandard2.0\Yuc.Helper.Dto.pdb" target="lib\netstandard2.0" /><file src="Yuc.Helper.Client\bin\$configuration$\net461\Yuc.Helper.Client.dll" target="lib\net461" /><file src="Yuc.Helper.Client\bin\$configuration$\net461\Yuc.Helper.Client.pdb" target="lib\net461" /><file src="Yuc.Helper.Client\bin\$configuration$\net461\Yuc.Helper.Client.xml" target="lib\net461" /><file src="Yuc.Helper.Client\bin\$configuration$\net461\Yuc.Helper.Dto.dll" target="lib\net461" /><file src="Yuc.Helper.Client\bin\$configuration$\net461\Yuc.Helper.Dto.pdb" target="lib\net461" /></files></package>
Cet exemple est volontairement simple, n’hésitez pas à consulter la documentation officielle pour découvrir les autres fonctionnalités utilisables dans le fichier .nuspec.
En temps normal, ce fichier .nuspec est utilisé par un build VSTS pour générer le package Nuget qui est ensuite publié sur notre dépôt privée Nuget VSTS. En l’état actuel, il pourrait également être utilisé en local de la même façon, c’est ce que nous allons faire plus loin.
Nouveautés VS 2017 et .NET Core
Pour les projets .NET Standard ou .NET Core, dans Visual Studio 2017, il est maintenant possible de préciser les métadonnées du fichier .nuspec pour que MSBuild s’occupe de la génération du package lors du build. Alternative intéressante à connaître, plus de détails sur l’article du blog Nuget (en anglais).
Test du package en local
Pour tester correctement le package, il va être nécessaire de générer celui-ci en local et de l’utiliser dans une application.
A ce stade, l’objectif est de s’assurer que le package pourra être correctement utilisé une fois publié. Cela permet de tester les points suivants :
- Configuration .nuspec correcte : pas de dépendances ou références manquantes.
- Mise à jour possible depuis une application existante.
En fonction du package ou de l’endroit où il est utilisé, le second point n’est pas forcément possible ou simple à faire. Dans ces cas là on peut se limiter à un test d’utilisation dans un programme console ou un script LINQPad.
Ajout d’un dépôt Nuget local
Pour pouvoir tester des packages Nuget en local, il faut déclarer un nouveau dépôt Nuget dans votre gestionnaire de package Nuget. Cela permettra d’y déposer les packages que nous générerons en local.
Sur Visual Studio, il faut aller dans le menu Tools > Options > NuGet Package Manager > Package Sources et ajouter un répertoire local qui servira de dépot (« D:\_Nuget — Local » dans mon cas).
Pour les autres outils, une manipulation similaire doit être disponible si celui-ci dispose d’un gestionnaire de package Nuget.
Génération du package
Pour tester le package en local, j’utilise une ligne de commande PowerShell pour générer le package et le copier dans le répertoire de mon dépôt Nuget local.
Pour cela, vous aurez besoin d’avoir l’exécutable Nuget (téléchargeable ici). Pour me simplifier la vie, je l’ai copié à la racine de mon disque D.
Je peux ensuite utiliser la ligne de commande suivante pour générer mon package :
D:\nuget pack C:\VSTS\Yuc.Helper.Client\Yuc.Helper.Client.nuspec -OutputDirectory 'D:\_Nuget - Local\Yuc.Helper.Client' -Properties Configuration=ReleaseConsultez la documentation de référence de la commande pack si vous devez ajouter d’autres paramètres.
Pour vérifier que cela a bien fonctionné, ouvrez votre gestionnaire de package Nuget dans Visual Studio et sélectionnez le dépôt Local que vous avez ajouté précédemment. Vous devriez voir votre nouveau package !
Remarque à propos des numéros de version utilisés
Quand vous générez votre package en local, vous pouvez mettre un numéro de version fictif et arbitraire. Il faut juste faire attention à ce que le numéro utilisé soit supérieur à celui de la dernière version existante. En effet, si vous testez la mise à jour du package dans une application existante, la mise à jour n’apparaitra pas si le numéro de version de votre package créé localement est inférieur à l’existant.
Pour préciser le numéro de version, modifier le numéro dans le fichier .nuspec ou préciser celui-ci via le paramètre -Version de la commande pack.
Conclusion
Comme vous avez pu le voir, il n’est pas compliqué de tester en local la mise à jour d’un package. Cela peut parfois permettre de détecter des petits oublis qui auraient été détectés plus tardivement.
Dans certaines situations, le test en local n’est pas suffisant. Dans ce genre de cas, nous utilisons un build VSTS pour créer un package prerelease qui sera publié sur notre dépôt Nuget privé. Cela permet à différent projets de valider la modification avant de publier la version définitive du package.
