Recherchez et évaluez des packages NuGet pour votre projet

Lorsque vous démarrez un projet .NET ou que vous identifiez un besoin fonctionnel dans votre application ou votre service, vous pouvez souvent installer des packages NuGet existants pour gagner du temps et éviter les problèmes liés à la création de vos propres packages. Les packages existants peuvent provenir de la collection publique nuget.org, ou d’une source privée fournie par votre organisation ou par un tiers.

Rechercher des packages

Vous pouvez trouver des packages directement à partir de https://nuget.org/packages ou à partir de l’interface utilisateur du Gestionnaire de package de Visual Studio ou de la console du gestionnaire de package avec nuget.org en tant que source. Tous les packages de nuget.org sont régulièrement analysés à la recherche d’éventuels virus.

Sur nuget.org/packages, vous pouvez trouver une liste de packages NuGet avec les packages les plus populaires dans tous les projets .NET répertoriés en premier. Certains de ces packages peuvent être utiles pour l’ensemble de vos projets.

Pour rechercher un package, saisissez le nom du package ou les critères de recherche dans la zone de recherche en haut de la page. Vous pouvez utiliser la syntaxe de recherche avancée pour filtrer votre recherche.

Filtrage et tri avancés

Sur nuget.org/packages, vous pouvez affiner les résultats de la recherche en utilisant les options de filtrage et de tri avancées.

Utilisez les filtres Frameworks pour afficher les packages ciblant des frameworks .NET spécifiques (pour plus d’informations, consultez Versions cibles de .Net Framework) :

• La sélection de l’une des case activée boxes de génération du .NET Framework filtrerait les résultats de recherche sur les packages compatibles avec l’un des frameworks cibles individuels au sein de cette génération. Par exemple, la .NET sélection retourne des packages compatibles avec l’un des frameworks .NET modernes, notamment net5.0 via net8.0.

  

• L’expansion de l’une de ces générations de framework avec les flèches situées à droite vous montre les monikers de framework cible (TFM) individuels que vous pouvez filtrer vos résultats. Par exemple, la net5.0 sélection renvoie les packages compatibles avec le framework « .NET 5.0 ».

• Par défaut, les packages sont filtrés par leur liste développée d’infrastructures compatibles calculées. Si vous souhaitez filtrer les packages uniquement par les frameworks de ressources qu’ils ciblent explicitement, désélectionnez les frameworks compatibles Include case activée box.

• La combinaison de plusieurs filtres d’infrastructure vous montre les résultats de recherche qui correspondent à tous vos filtres sélectionnés, c’est-à-dire les packages qui tombent dans l’intersection de vos sélections. Par exemple, sélectionner netcoreapp3.1 et net45 affiche les packages qui ciblent à la fois « .NET Core 3.1 » et « .NET Framework 4.5 ». La sélection de la case à cocher .NET Core concernant la génération du framework et la case à cocher net45 retourne les packages qui ciblent « .NET Framework 4.5 », et au moins l’un des TFM « .NET Core » (netcoreapp1.0 via netcoreapp3.1).

  • Sinon, si vous souhaitez afficher des packages correspondant à l’un de vos filtres d’infrastructure, sélectionnez la case d’option N’importe quelle case d’option sur l’option Mode filtre de l’infrastructure. À présent, la netcoreapp3.1 sélection et net5.0 affiche les packages qui ciblent « .NET Core 3.1 » ou « .NET 5.0 ». La sélection du netcoreapp3.1 case activée box et de la .NET génération d’infrastructure case activée box retournent ensemble les packages qui ciblent « .NET Core 3.1 » ou l’un des « . TFMs de NET (net5.0 via net8.0).

• Vous pouvez en savoir plus sur la façon d’évaluer les frameworks pris en charge d’un package et sa compatibilité avec votre projet ici.

Utilisez le filtre de Type de package pour afficher les packages d’un type spécifique :

• Tous les types est la valeur par défaut et affiche tous les packages quel que soit le type.
• Dépendance filtre et n’affiche que les packages NuGet standard que vous pouvez installer dans votre projet.
• Outil .NET filtre et n’affiche que les packages d’outils .NET qui contiennent des applications console.
• Modèle filtre et n’affiche que les modèles .NET que vous pouvez utiliser pour créer de nouveaux projets avec la commande dotnet new.

Par défaut, NuGet répertorie toutes les versions des packages, y compris les versions préliminaires et bêta. Dans la section Options, désélectionnez la case à cocher Inclure les préversions pour répertorier uniquement les versions stables et publiées du package.

Pour appliquer les modifications, sélectionnez Appliquer. Pour revenir aux valeurs par défaut, sélectionnez Réinitialiser.

Utilisez la liste déroulante Trier par en haut à droite de la page pour trier la liste selon plusieurs critères :

• Par pertinence est la valeur par défaut et trie les résultats en fonction d’un algorithme de scoring interne.
• Téléchargement trie les résultats de la recherche en fonction du nombre total de téléchargements, dans l’ordre décroissant.
• Récemment mis à jour trie les résultats de la recherche selon la date de création de version du package la plus récente, dans l’ordre chronologique décroissant.

Syntaxe de recherche

Les requêtes de recherche de package sur nuget.org, à partir de l’interface CLI NuGet et à partir de Visual Studio utilisent toutes la même syntaxe. D’autres sources de package, comme Azure Artifacts ou GitHub Package Repository, peuvent utiliser une syntaxe différente ou ne pas prendre en charge le filtrage avancé.

• Vous pouvez rechercher dans les propriétés de package id, packageid, version, title, tags, author, description, summary, ou owner à l’aide de la syntaxe <property>:<term>.

• La recherche s’applique aux mot clé et aux descriptions, et ne respecte pas la casse. Par exemple, les chaînes suivantes recherchent toutes la propriété id de la chaîne nuget.core :

  id:NuGet.Core
ID:nuget.core
Id:NUGET.CORE

• Les recherche sur les propriétés id correspondent aux sous-chaines, alors que packageid et owner utilisent des correspondances insensibles à la casse exactes. Par exemple :

  PackageId:jquery recherche l’ID de package jquery exact.
  Id:jquery recherche tous les ID de package qui contiennent la chaîne jquery.

• Vous pouvez effectuer des recherches pour plusieurs valeurs ou plusieurs propriétés en même temps. Par exemple :

  id:jquery id:ui recherche plusieurs termes dans la propriété id.
  id:jquery tags:validation recherche plusieurs propriétés.

• La recherche ignore les propriétés non prises en charge. invalid:jquery ui est donc identique à la recherche ui, et invalid:jquery retourne tous les packages.

Déterminer les frameworks pris en charge

NuGet installe un package dans un projet uniquement si les frameworks .NET pris en charge par ce package comprennent la version cible de .NET Framework du projet. Si le package n’est pas compatible, NuGet affiche un message d’erreur.

Il existe plusieurs façons de déterminer les frameworks pris en charge par un package :

• Dans la page de recherche, les frameworks pris en charge d’un package s’affichent sous la forme de badges sous l’ID du package. Ces badges affichent les versions de framework les plus basses prises en charge à partir des générations .NET, .NET Core, .NET Standard et .NET Framework . Le package est compatible avec n’importe quelle version du framework égale ou supérieure à la version du badge affichée.

  Les badges « bleu foncé » représentent des frameworks explicitement ciblés, tandis que les badges « bleu clair » représentent des infrastructures compatibles calculées.

  Cliquez sur un badge pour vous rediriger vers la page de détails du package sur nuget.org. L’onglet Frameworks de la page du package affiche la liste complète des frameworks pris en charge.

  

• Sur la page du package sur nuget.org, les frameworks pris en charge apparaissent sous l’ID de package et sous l’onglet Frameworks, mais tous les packages n’affichent pas les frameworks pris en charge.

  

• Téléchargez le package manuellement en sélectionnant Télécharger le package sous À propos. Modifiez l’extension de fichier du package téléchargé de .nupkg à .zip, ouvrez le dossier .zip et examinez le dossier lib. Il s’y trouve les sous-dossiers de chacun des frameworks pris en charge. Chaque sous-dossier est nommé avec un moniker de framework cible (TFM). Pour plus d’informations, consultez Versions cibles de .Net Framework. S’il n’existe aucun sous-dossier sous lib et qu’il n’existe qu’une seule DLL, essayez d’installer le package pour découvrir sa compatibilité.

• Essayez d’installer un package dans un projet à l’aide Install-Package avec la console de gestionnaire de package de Visual Studio. Si le package est incompatible, la sortie de la console affiche les frameworks qui sont pris en charge par le package.

Packages de préversion

De nombreux auteurs de package sortent des préversions et des versions bêta, car ils continuent d'améliorer ces versions et cherchent à obtenir des commentaires à leur sujet. Par défaut, nuget.org affiche les packages de préversion dans la liste de package et dans les résultats de la recherche.

Pour répertorier et rechercher uniquement les versions stables :

• Sur nuget.org, désélectionnez la case à cocher Inclure les préversions dans le volet de recherche avancé.
• Dans l’interface utilisateur du gestionnaire de package NuGet de Visual Studio, désélectionnez la case à cocher Inclure les préversion en regard de la zone de recherche.

Par défaut, la console du gestionnaire de package de Visual Studio, les outils de l’interface CLI NuGet et les outils de l’interface CLI n’incluent pas les versions préliminaires. Pour inclure les versions préliminaires :

• Dans la console du gestionnaire de package, utilisez le commutateur -IncludePrerelease avec les commandes Find-Package, Get-Package, Install-Package, Sync-Package, et Update-Package. Pour plus d’informations, consultez la Référence PowerShell.

• Pour l’interface CLI NuGet, utilisez le commutateur -prerelease avec les commandes install, update, delete et mirror. Pour plus d’informations, consultez la référence de l’interface CLI NuGet.

• Pour l’interface CLI dotnet, spécifiez une version préliminaire avec l’argument -v. Pour plus d’informations, consultez la référence dotnet add package.

Packages C++ natifs

Les projets Visual Studio C++ peuvent utiliser des packages NuGet C++ natifs. L’installation de ces packages active la commande de menu local Gérer les packages NuGet, expose une version cible de .NET Framework native et fournit une intégration MSBuild.

Pour rechercher des packages natifs sur nuget.org/packages, effectuez une recherche à l’aide de tag:native. Ces packages fournissent généralement des fichiers .targets et .props, que NuGet importe automatiquement lorsque le package est ajouté.

Évaluer des packages

La meilleure façon d’évaluer l’utilité d’un package consiste à l’essayer. Vous dépendez de ce package lorsque vous l’utilisez. Vous devez donc vous assurer qu’il est robuste et fiable. Cependant, l’installation d’un package et le tester directement prend beaucoup de temps. Vous pouvez en apprendre beaucoup sur la qualité d’un package en utilisant les informations sur la page du package sur nuget.org/packages.

• La coche de préfixe réservé en regard de l’ID de package dans la liste des packages et sur la page du package signifie que les propriétaires de package ont appliqué et ont reçu un préfixe d’ID de package réservé. Pour répondre aux critères de réservation de préfixe d’ID, les propriétaires de package doivent clairement s’identifier eux-mêmes ainsi que leurs packages.

  

• Téléchargements dans la colonne à droite de la page de package affiche le nombre Total de téléchargement, la version actuelle et le nombre de téléchargements moyen par jour. De grands nombres indiquent que le package est utilisés par de nombreux développeurs.

  

  Sélectionnez Statistiques complètes en regard Téléchargements pour afficher une page qui affiche les téléchargements de package au cours des six dernières semaines par numéro de version. Les versions les plus utilisées par développeurs sont généralement de meilleurs choix.

• L’onglet Utilisé par dans la page du package affiche les cinq principaux packages nuget.org et référentiels GitHub les plus populaires qui dépendent de ce package. Les packages et les référentiels qui dépendent de ce package sont appelés dépendants. Les packages et les référentiels dépendants peuvent être considérés comme des approbations de ce package, car ils ont choisi de faire confiance et de dépendre de celui-ci.

  

  La dernière version stable d’un package dépendant doit dépendre de n’importe quelle version de ce package. Cette définition garantit que les packages dépendants répertoriés sont une réflexion à jour des décisions des auteurs de packages à approuver et qui dépendent du package. La liste des dépendants n’affiche pas encore les dépendances de préversion, car elles ne sont pas encore considérées comme des approbations complètes. Les exemples suivants montrent les packages qui s’affichent en tant que dépendants :

  Version de package dépendant	Package dépendant répertorié comme dépendant ?
  v1.0.0 V1.1.0 (dernière version stable) dépend de ce package v1.2.0-preview	TRUE, la dernière version stable dépend de ce package
  v1.0.0 dépend de ce package v1.1.0 (dernière version stable) v1.2.0-preview	FALSE, la dernière version stable ne dépend pas de ce package
  v1.0.0 dépend de ce package v1.1.0 (dernière version stable) v1.2.0-preview dépend de ce package	FALSE, la dernière version stable ne dépend pas de ce package

  Le nombre d’étoiles d’un référentiel GitHub indique sa popularité auprès des utilisateurs GitHub. Pour plus d’informations sur le système de classement par étoiles et du classement des référentiels GitHub, consultez À propos des étoiles.

  Remarque

  La section Utilisée par est générée automatiquement, sans révision humaine, et à des fins d’information uniquement.

• L’onglet Versions de la page du package affiche les Versions, les Téléchargements, les dates de Dernière mise à jour et les vulnérabilités graves des versions du package. La version que vous installez ne doit pas avoir de vulnérabilités de gravité élevée. Un package bien géré doit comprendre des mises à jour récentes et un historique des versions très fourni. Les packages négligés ont peu de mises à jour et datant d’il y a longtemps.

  

La colonne de droite de la page de package comporte d’autres liens informatifs :

• Sélectionnez le site web du projet, le cas échéant, pour voir quelles options de support sont fournies par l’auteur. Un projet avec un site dédié est généralement bien pris en charge.

• Sélectionnez Référentiel source pour accéder au référentiel de code source Git pour le package. De nombreux auteurs gèrent leurs packages dans des référentiels open source, afin que les utilisateurs puissent contribuer directement aux correctifs de bogues et aux améliorations des fonctionnalités. L’historique des contributions d’un package donné est également un bon indicateur du nombre de développeurs activement impliqués.

• Sélectionnez la licence < de type licence > pour afficher la licence MIT du package ou une autre licence. Si un package ne spécifie pas de termes du contrat de licence, contactez le propriétaire du package.

• Sélectionnez un propriétaire de package sous Propriétaire pour voir les autres packages qu’il a publiés. Les développeurs qui ont publié plusieurs packages sont davantage susceptibles de continuer la prise en charge de leur package. Sélectionnez Contacter les propriétaires à côté de Propriétaires pour contacter directement les développeurs de packages.

Récupérer les informations de licence

Certains clients NuGet et flux NuGet peuvent ne pas être en mesure de présenter les informations de gestion des licences. Pour maintenir une compatibilité descendante dans ces situations, l’URL de la licence pointe vers ce document, relatif à la manière de récupérer les informations de licence.

Si vous sélectionnez l’URL de la licence pour un package qui vous amène sur cette page, cela signifie que le package contient un fichier de licence et :

• Vous êtes connecté à un flux qui ne sait pas encore comment interpréter et afficher les informations de licence pour le client, ou
• Vous utilisez un client qui ne sait pas encore comment interpréter et lire les informations de licence fournies par le flux ou
• Une combinaison de ces deux scénarios.

Pour lire les informations du fichier de licence à l’intérieur du package :

1. Téléchargez manuellement le package et décompressez son contenu dans un dossier.
2. Ouvrez le fichier .nuspec à la racine du dossier.
3. Examinez la balise<license>, par exemple <license type="file">license\license.txt</license>. L’exemple de balise indique que le fichier de licence est nommé license.txt et se trouve à l’intérieur d’un sous-dossier appelé licence.
4. Accédez à l’emplacement spécifié et ouvrez le fichier spécifié.

Pour en savoir plus sur l’équivalent MSBuild de la définition de la licence dans le .nuspec, consultez Emballage d’une expression de licence ou d’un fichier de licence.

Étapes suivantes

• Méthodes d’installation d’un package NuGet
• Installer et gérer des packages dans Visual Studio à l’aide du gestionnaire de package NuGet
• Installer et gérer des packages avec la console du gestionnaire de package dans Visual Studio
• Installer et gérer des packages à l’aide de l’interface CLI dotnet