Choisissez le Bon Gestionnaire de Paquets Nuget et Configurez-le avec IIS

Vous avez développé une application ou peut-être même un ensemble de scripts importants et vous avez besoin de les empaqueter et de les déployer. Ne cherchez pas plus loin que NuGet et les différents gestionnaires de paquets NuGet disponibles.

Dans cet article, vous allez apprendre comment configurer différents gestionnaires de paquets NuGet pour la première fois afin de pouvoir les utiliser immédiatement.

Articles connexes : Configurer un serveur NuGet sous Windows (Guide complet)

Configuration d’un wrapper NuGet.Server

La configuration d’un NuGet.Server à partir de zéro n’est pas trop compliquée, mais cela peut prendre du temps pour quelqu’un de nouveau à Visual Studio et à IIS. Une façon d’accélérer la configuration et le processus de mise à jour consiste à utiliser un wrapper. L’un des wrappers les plus populaires, appelé nuget-server, a été écrit par svenkle et peut être trouvé sur leur page Github.

Une des principales différences lors de l’utilisation de ce wrapper au lieu d’installer manuellement le serveur web est qu’il utilise IIS Express. Vous pouvez en savoir plus sur les différences sur le site web de Microsoft.

Il y a deux différences importantes entre la configuration d’un NuGet.Server classique et celle avec ce wrapper :

• vous devez créer un service Windows pour démarrer le serveur web
• vous ne pouvez pas utiliser le Gestionnaire IIS pour la configuration

L’inconvénient principal de l’utilisation d’un wrapper pour installer NuGet.Server est que vous ne pouvez pas facilement mettre à jour la version tant que le wrapper n’est pas mis à jour.

Prérequis

Si vous souhaitez apprendre à configurer ce wrapper NuGet.Server, vous devrez d’abord vous assurer d’avoir ce qui suit :

• Installateur pour le wrapper NuGet.Server de svenkle
• Windows Server – Toute version actuellement prise en charge de Windows Server fonctionnera, mais toutes les captures d’écran ont été réalisées sur Windows Server 2019 Standard

Installation du service de serveur Web

La première étape consiste à créer un nouveau service Windows. Étant donné que ce wrapper NuGet.Server n’utilise pas IIS, vous ne pouvez pas l’utiliser en parallèle avec IIS.

Avec le fichier NuGetServer.zip téléchargé depuis la page des versions, décompressez le fichier dans le répertoire de votre choix sur le serveur Web. Une fois décompressé, créez le service Windows pour démarrer automatiquement la page Web lorsque vous démarrez le serveur. Vous trouverez ci-dessous une commande PowerShell pour le faire pour vous.

New-Service -Name NuGetServer -BinaryPathName '<UnzipPath>\Svenkle.NuGetServer.Service.exe' -StartupType Automatic
Start-Service -Name NuGetServer

Personnalisation du serveur Web

Maintenant que vous avez installé NuGet.Server à partir de l’enveloppe et que le service est créé et démarré, il est temps de personnaliser le fichier web.config. Vous pouvez apporter les mêmes modifications que celles que vous feriez au fichier web.config avec un déploiement manuel si vous le souhaitez.

Le fichier web.config se trouve dans le dossier <UnzipPath>\Host\Website. La principale différence avec ce déploiement est qu’il utilise le port 8080 au lieu du port HTTP par défaut 80. Cela signifie que partout où vous auriez utilisé l’URL web, vous devez ajouter :8080, par exemple lorsque vous accédez à la page web, cela serait http://localhost:8080/nuget.

C’est terminé. C’était beaucoup plus facile que d’utiliser Visual Studio !

Configuration de BaGet sur IIS

Pendant que vous n’avez regardé que des versions de stock de NuGet.Server jusqu’à présent, il existe de nombreuses autres versions disponibles. Un gestionnaire de packages NuGet populaire est un projet open-source appelé BaGet.

Voyons ce qu’il faut pour installer et exécuter BaGet sur un serveur Windows avec IIS.

Prérequis

Avant de commencer, assurez-vous de respecter quelques prérequis.

• BaGet.zip – Au moment de la rédaction de cet article, le projet est encore en préversion et j’utilise la version 0.1.77
• .NET Core Runtime & Hosting Bundle – Cela devra être téléchargé et disponible sur le serveur web ultérieurement.
• Windows Server – Toute version actuellement prise en charge de Windows Server fonctionnera, mais toutes les captures d’écran ont été réalisées sur Windows Server 2019 Standard

Installation des prérequis du serveur Web

Bien que les étapes ci-dessous puissent être exécutées sur Linux avec .NET Core ou dans une image Docker, ces instructions seront utilisées pour installer BaGet sur un serveur Windows. De cette façon, vous pouvez profiter de IIS pour démarrer et arrêter votre serveur.

Installez IIS

Étant donné que BaGet s’exécute sur .NET Core, il n’y a pas autant d’exigences que le serveur NuGet de base pour lequel vous avez installé IIS précédemment. Vous avez seulement besoin d’un serveur web IIS par défaut et du gestionnaire IIS. Pour les installer, ouvrez une session PowerShell sur votre serveur web et exécutez :

Install-WindowsFeature Web-Server -IncludeManagementTools

Installez .NET Core

Ensuite, installez le bundle .NET Core sur le serveur web. Pour ce faire, exécutez le fichier exe que vous avez téléchargé précédemment. Vous pouvez laisser toutes les options par défaut pour cette installation.

Le bundle .NET Core doit être installé après IIS. Si cela ne se produit pas dans le bon ordre, vous devrez réexécuter l’installateur du bundle .NET Core et sélectionner « Réparer » pour ajouter les exigences manquantes pour une application web.

Maintenant que vous avez les composants du serveur web prêts, décompressez le fichier BaGet.zip téléchargé précédemment et placez-le dans le dossier C:\inetpub\wwwroot de votre serveur web.

Configuration de l’application du serveur web

Similaire à NuGet.Server, vous devrez configurer quelques composants IIS pour faire fonctionner le gestionnaire de packages NuGet, BaGet.

Création du pool d’applications IIS pour BaGet

Ouvrez Gestionnaire IIS sur le serveur web et accédez à Pools d’applications. Créez un nouveau pool d’applications pour BaGet, car il n’utilisera pas de code géré .NET. Vous pouvez lui donner le nom de votre choix. Voici à quoi cela devrait ressembler.

Création du site web BaGet

Une fois le pool d’applications créé, créez le site web. Comme BaGet utilise un port HTTP non standard et un pool d’applications non par défaut, il est plus facile de créer un site web séparé à partir du Site Web par défaut. Pour ce faire, faites un clic droit sur le dossier Sites dans Gestionnaire IIS et sélectionnez Ajouter un site web.

Voici les paramètres que vous devez configurer pour BaGet.

Une fois le site configuré, il devrait démarrer automatiquement. Vous pouvez y accéder en allant sur http://localhost:5000/ depuis votre serveur.

Vous remarquerez qu’il y a une interface utilisateur plus développée sur la page web de BaGet par rapport à celle de NuGet.Server standard. Dans BaGet, vous pouvez facilement rechercher des packages qui ont été téléchargés et il fournit également les commandes pour les télécharger de différentes manières, au lieu d’utiliser les options de ligne de commande NuGet.

Personnalisation du serveur web BaGet

Rappelez-vous que vous avez pu personnaliser votre serveur NuGet.Server en utilisant le fichier web.config. Mais le gestionnaire de packages NuGet BaGet n’utilise pas le fichier web.config. Au lieu de cela, puisque BaGet peut également être utilisé sur Linux, les développeurs ont opté pour un format plus multiplateforme avec un fichier JSON appelé appsettings.json. Il se trouve dans le dossier C:\inetpub\wwwroot\BaGet.

Notez que, étant donné que BaGet utilise .NET Core pour sa fonctionnalité multiplateforme, tous les chemins utilisent des barres obliques inverses.

Par exemple, si vous souhaitez avoir votre chemin de package à C:\Packages sur votre serveur, vous devrez avoir ce qui est indiqué ci-dessous dans le fichier appsettings.json.

"Storage": {
    "Type": "FileSystem",
    "Path": "C://Packages"
}

Clé API BaGet

Pour protéger votre serveur NuGet des utilisateurs non autorisés qui souhaiteraient publier ou supprimer un package, vous voudrez toujours définir une clé API. Le paramètre de clé API se trouve également dans le fichier appsettings.json, vous pouvez donc le définir pendant que vous y êtes.

Étant donné que j’utilise PowerShell pour gérer mes packages NuGet, je peux à nouveau enregistrer un PSRepository. Pour BaGet, accédez à la page web que vous avez créée. La page web vous donnera la commande à exécuter dans votre session PowerShell. Par exemple :

Register-PSRepository -Name "BaGet" -SourceLocation "http://<WebServer>:5000/v3/index.json" -PublishLocation "http://<WebServer>:5000/api/v2/package" -InstallationPolicy "Trusted"

Comprendre les forks de BaGet (LiGet)

Bien que BaGet offre de nombreuses options d’utilisation, d’autres forks de BaGet ont été créés pour se spécialiser dans d’autres domaines de NuGet. L’un des forks les plus populaires est LiGet. LiGet est différent car il se spécialise dans une approche axée sur Linux en premier lieu.

LiGet est une version dérivée du gestionnaire de packages NuGet du projet original pour BaGet. Les développeurs ont décidé de le faire pour se concentrer sur certaines fonctionnalités spécifiques de NuGet, notamment la prise en charge du flux v3. La prise en charge du flux v3 n’affecte pas l’utilisation de PowerShell. Mais si vous prévoyez d’héberger un serveur NuGet pour d’autres cas d’utilisation, vous apprécierez les fonctionnalités supplémentaires.

La clé d’API hachée de LiGet

Une différence majeure entre LiGet et BaGet réside dans l’utilisation d’une clé d’API hachée au lieu d’un texte en clair. Avec une clé en texte brut, quelqu’un ayant accès au fichier web.config sur NuGet.Server ou au fichier appsettings.json sur BaGet pourrait publier sur le serveur. Cela ne pourrait pas se produire avec LiGet.

Pour mettre en place LiGet, vous devrez créer une clé d’API hachée et la placer dans le fichier appsettings.json dans le dossier C:\inetpub\wwwroot\LiGet.

Pour créer le hachage, vous pouvez utiliser PowerShell ou toute autre méthode de hachage avec laquelle vous êtes à l’aise. Voici un exemple de ce que vous exécuteriez sur votre poste de travail pour créer un hachage.

([System.Security.Cryptography.HashAlgorithm]::Create('SHA256').ComputeHash([System.Text.Encoding]::UTF8.GetBytes(<apikey>)) | 
Foreach-Object { $_.ToString('x2')}) -join ''

Vous pouvez également utiliser un générateur de hachage en ligne pour créer le hachage.

L’inconvénient de cette approche est que si vous oubliez la clé d’API, vous devez créer un nouveau hachage et le remplacer, car le hachage n’est pas réversible.

Configuration de ProGet sur IIS.

Toutes les options qui ont été couvertes jusqu’à présent sont gratuites et n’ont pas beaucoup de pièces mobiles une fois configurées. Bien que cela soit bien pour essayer NuGet, si vous souhaitez intégrer d’autres outils ou si vous avez besoin du support du fournisseur pour un système sur le lieu de travail, une meilleure option pourrait être le gestionnaire de packages NuGet ProGet.

Prérequis

Pour configurer ProGet, vous aurez besoin de quelques prérequis courants avec l’ajout éventuel d’une base de données SQL facultative.

• Windows Server – Toute version actuellement prise en charge de Windows Server fonctionnera, mais toutes les captures d’écran ont été réalisées sur Windows Server 2019 Standard
• Installateur ProGet – La version de ProGet que j’utilise est la 5.2.9.
• Instance SQL – C’est facultatif car ProGet propose une option pour installer SQL Express à partir de l’installateur, bien que cela nécessite une connexion Internet depuis votre serveur pour effectuer le téléchargement initial

Installation de ProGet

Exécutez l’installateur ProGet depuis votre serveur web. Comme vous configurez IIS, sélectionnez l’option serveur web IIS lors de l’installation de ProGet. Si vous n’avez pas déjà IIS installé, il sera installé lors de l’installation de ProGet.

Le reste des options peut être laissé par défaut, à moins que vous ne souhaitiez héberger la base de données ProGet sur un serveur SQL séparé. Dans ce cas, vous devrez spécifier l’instance SQL à utiliser.

Si vous laissez l’option Serveur SQL comme Installer l’instance Inedo, il installera le serveur SQL Express pour vous.

Une fois l’installation terminée, lancez le site Web lorsque vous y êtes invité et vous devriez voir une page Web s’afficher qui ressemble à la capture d’écran ci-dessous.

Configuration d’un PSRepository sur ProGet

À ce stade, ProGet est installé. C’est assez facile. Comme nous utilisons PowerShell pour travailler avec les packages NuGet, nous devrons configurer un PSRepository comme nous l’avons déjà fait.

Pour configurer ProGet pour un PSRepository, accédez à l’onglet Feeds et créez un nouveau feed. Vous pouvez donner n’importe quel nom au feed. Ensuite, sélectionnez Format de package tiers et PowerShell comme indiqué ci-dessous.

Une fois que vous avez créé le feed, retournez à l’onglet Feeds, sélectionnez votre nouveau feed et l’URL utilisée pour la publication s’affichera. C’est ce que vous devrez exécuter dans PowerShell sur un appareil pour publier ou télécharger à partir de ce PSRepository.

Voici ce qui a été affiché avec l’exemple ci-dessus:

Register-PSRepository -Name ProGet -SourceLocation http://<WebServer>:8624/nuget/PSRepository/ -PublishLocation http://<WebServer>:8624/nuget/PSRepository/ -InstallationPolicy Trusted

Ajout d’une clé d’API

Comme pour les autres options, vous devez générer une clé d’API. Pour ce faire, cliquez sur l’icône de l’engrenage en haut à droite, puis sélectionnez Clés d’API dans la barre d’outils de gauche. Ici, vous pouvez voir les clés d’API existantes et en créer de nouvelles. Vous verrez immédiatement une différence majeure entre ProGet open-source et ProGet Enterprise. Avec ProGet, vous pouvez avoir plusieurs clés d’API.

Sur l’écran des clés d’API, cliquez sur Créer une clé d’API. À partir de là, cochez la case Feed API et cliquez sur Enregistrer la clé d’API.

Une fois la clé d’API créée, vous serez renvoyé à la page des clés d’API. À partir de là, vous pouvez utiliser la clé d’API que vous voyez pour publier des packages dans votre flux.

Recherche de packages avec ProGet

ProGet comprend également une page web qui vous permet de rechercher tous les packages NuGet du flux, de voir leur nombre de téléchargements, le nom des modules PowerShell, dans quel flux un package a été téléchargé, ainsi que d’autres statistiques similaires sur les packages, depuis la page Packages comme indiqué ci-dessous.

Alternativement, vous pouvez vous rendre sur la page Feeds et sélectionner un flux pour voir uniquement les packages de ce flux. Vous pouvez ensuite accéder aux packages individuels pour voir les statistiques et les autres détails à leur sujet, comme indiqué ci-dessous.

Mise à jour de ProGet

L’un des avantages d’utiliser un produit conçu pour les entreprises est que certaines tâches administratives plus longues sont beaucoup plus rapides. Un exemple en est la mise à jour de ProGet.

Pour mettre à jour ProGet vers la dernière version, il vous suffit d’ouvrir l’Installateur Inedo sur votre serveur web. Celui-ci a été installé lors de la première installation de ProGet. Cliquez sur le bouton Mettre à jour comme indiqué ci-dessous et l’installateur fera le reste pour vous.

Comparaison des gestionnaires de packages NuGet

Vous avez appris beaucoup de choses sur différents outils NuGet dans cet article. Si vous êtes encore à la recherche de celui à essayer, dans cette section, vous aurez un aperçu de ce qui les différencie les uns des autres.

BaGet vs. LiGet

Étant donné que LiGet est une bifurcation de BaGet, ils partagent de nombreuses similitudes, y compris la plupart du processus de configuration. En fait, vous pouvez suivre la même procédure de configuration exacte que BaGet.

Une fois installés, LiGet et BaGet partagent certaines fonctionnalités mais diffèrent également d’autres manières.

Alors que la plupart de ces différences n’affectent pas l’utilisation avec PowerShell, la configuration change légèrement en raison de l’utilisation d’une clé d’API hachée.

BaGet et LiGet sont tous deux construits sur .NET Core, ce qui les rend multiplateformes et utilisables sur des systèmes d’exploitation Linux ainsi que sur Windows. Les deux disposent également d’images Docker disponibles qui, si vous utilisez déjà un service de conteneur, peuvent accélérer et faciliter la configuration.

Avec les quelques différences entre LiGet et BaGet, les deux options sont excellentes pour un serveur NuGet open source et adapté aux conteneurs. Les deux options vous permettent de vous familiariser avec un serveur NuGet sur Windows tout en vous permettant de passer à Linux ou à une image Docker à l’avenir sans trop de travail supplémentaire.

BaGet vs ProGet

Si vous préférez ne pas créer votre propre solution en partie et prendre la voie facile, il y a toujours ProGet. Cependant, il y a des inconvénients. ProGet n’est pas open source et n’est en aucun cas gratuit. Mais il est plus facile à configurer et à utiliser.

Il y a quelques différences majeures entre ProGet et BaGet.

Inedo propose également une comparaison de toutes les différences de fonctionnalités entre les versions de ProGet.

Résumé

Dans cet article, vous avez appris énormément de choses sur les différents outils et technologies NuGet. Si vous hésitiez sur le choix du serveur NuGet à utiliser, vous devriez maintenant avoir beaucoup plus de connaissances pour vous aider à prendre cette décision.

Vous avez appris comment configurer chaque outil NuGet pour qu’il fonctionne avec Windows et nous avons couvert de nombreuses fonctionnalités de chacun.