Rechercher et évaluer des packages NuGet pour votre projet

Lorsque vous démarrez un projet .NET ou que vous identifiez un besoin fonctionnel dans votre application ou service, vous pouvez souvent installer des packages NuGet existants pour gagner du temps et des problèmes de création de vos propres packages. Les packages existants peuvent provenir de la nuget.org collection publique ou de sources privées fournies par votre organisation ou un autre tiers.

Rechercher des packages

Vous pouvez trouver des packages directement à https://nuget.org/packagespartir de l’interface utilisateur du Gestionnaire de package 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 pour les virus.

À nuget.org/packages, vous voyez 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 vos projets.

Capture d’écran montrant l’affichage par défaut de nuget.org/packages avec les packages les plus populaires en haut.

Pour rechercher un package, entrez le nom du package ou les termes 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

À nuget.org/packages, vous pouvez sélectionner le bouton Filtrer en haut à droite pour développer les options avancées de tri et de filtrage.

Capture d’écran montrant le panneau Recherche avancée sur nuget.org.

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

  • Tous les types sont la valeur par défaut et affiche tous les packages, quel que soit le type.
  • Filtres de dépendances pour les packages NuGet standard que vous pouvez installer dans votre projet.
  • L’outil .NET filtre les packages d’outils .NET qui contiennent des applications console.
  • Filtres de modèle sur des modèles .NET que vous pouvez utiliser pour créer de nouveaux projets avec la commande dotnet new .

Utilisez l’option Trier par pour trier la liste selon plusieurs critères :

  • La pertinence est la valeur par défaut et trie les résultats en fonction d’un algorithme de scoring interne.
  • Les téléchargements trient les résultats de la recherche en fonction du nombre total de téléchargements, dans l’ordre décroissant.
  • La dernière mise à jour trie les résultats de la recherche selon la dernière date de création de la version du package, dans l’ordre chronologique décroissant.

Par défaut, NuGet répertorie toutes les versions de packages, y compris les versions préliminaires et bêta. Dans la section Options , décochez la case Inclure la préversion 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.

Syntaxe de recherche

Les requêtes de recherche de package à nuget.org, à partir de l’interface CLI NuGet et 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 le package id, packageidversiontitle, tags, authordescription, , ou summaryowner les propriétés à l’aide de la syntaxe .<property>:<term>

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

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

  • Recherche dans les id sous-chaînes de correspondance de la propriété, tandis que packageid et owner utilisez des correspondances exactes et ne respectant pas la casse. Par exemple :

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

  • Vous pouvez rechercher plusieurs valeurs ou propriétés en même temps. Par exemple :

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

  • La recherche ignore les propriétés non prises en charge. Elle est donc invalid:jquery ui identique à la recherche uiet 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 du package incluent les frameworks cibles du projet. Si le package n’est pas compatible, NuGet émet une erreur.

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

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

    Capture d’écran de l’interface utilisateur et de l’onglet Frameworks dans la page du package à nuget.org.

  • Téléchargez le package manuellement en sélectionnant Télécharger le package sous À propos de. Modifiez l’extension de fichier du package téléchargé à partir de .nupkg en .zip, ouvrez le dossier .zip et examinez son dossier lib . Il existe des sous-dossiers pour chaque infrastructure prise en charge, chacune nommée avec un moniker de framework cible (TFM). Pour plus d’informations, consultez Frameworks cibles. 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 le package dans un projet à l’aide d’Install-Package dans la console du Gestionnaire de package Visual Studio. Si le package est incompatible, la sortie de la console affiche les frameworks pris en charge du package.

Packages de préversion

De nombreux auteurs de packages fournissent des versions préliminaires et bêta, car ils continuent à améliorer et à rechercher des commentaires sur les dernières révisions. Par défaut, nuget.org affiche les packages de préversion dans sa liste de packages et ses résultats de recherche.

Pour répertorier et rechercher uniquement les versions stables :

  • À nuget.org, décochez la case Inclure la préversion dans le volet de recherche avancé.
  • Dans l’interface utilisateur du Gestionnaire de package NuGet de Visual Studio, décochez la case Inclure en regard de la zone de recherche.

La console du Gestionnaire de package Visual Studio, l’interface CLI NuGet et les outils cli dotnet n’incluent pas les versions préliminaires par défaut. Pour inclure des versions préliminaires :

  • Dans la console du Gestionnaire de package, utilisez le -IncludePrerelease commutateur avec les Find-Packagecommandes , les Install-PackageSync-Packagecommandes , les Update-PackageGet-Package Pour plus d’informations, consultez la référence PowerShell.

  • Pour l’interface CLI NuGet, utilisez le -prerelease commutateur avec les installcommandes , et updatedeletemirror les commandes. 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 Gérer les packages NuGet , expose une infrastructure cible et fournit une native 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 lors de l’ajout des packages.

Évaluer les packages

La meilleure façon d’évaluer l’utilité d’un package est de l’essayer. Vous prenez une dépendance sur un package lorsque vous l’utilisez. Vous devez donc vous assurer qu’il est robuste et fiable. Toutefois, l’installation d’un package et son test direct prend beaucoup de temps. Vous pouvez en apprendre beaucoup sur la qualité d’un package en utilisant les informations sur la page du package à nuget.org/packages.

  • La coche Préfixe réservé en regard de l’ID de package dans la liste des packages et de la page du package signifie que les propriétaires de package ont appliqué et 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 packages doivent clairement s’identifier et leurs packages.

    Capture d’écran montrant préfixe réservé sur la page d’un package.

  • Les téléchargements dans la colonne de droite de la page de package affichent le nombre total, la version actuelle et les téléchargements moyens par jour . De nombreux nombres indiquent que le package s’est avéré comme un grand nombre de développeurs.

    Capture d’écran montrant télécharger les statistiques sur la page d’un package.

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

  • L’onglet Utilisé par sur la page du package affiche les cinq principaux packages nuget.org et référentiels GitHub qui dépendent de ce package. Les packages et les dépôts qui dépendent de ce package sont appelés dépendants. Les packages et dépôts dépendants peuvent être considérés comme des références à ce package, car ils ont choisi d’approuver et de dépendre de celui-ci.

    Capture d’écran montrant la liste Utilisée par.

    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 à dépendre du package. La liste des dépendances 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 quels packages s’affichent en tant que dépendants :

    Version du 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, dernière version stable dépend de ce package
    v1.0.0 dépend de ce package
    v1.1.0 (dernière stable)
    v1.2.0-preview
    FALSE, dernière version stable ne dépend pas de ce package
    v1.0.0 dépend de ce package
    v1.1.0 (dernière stable)
    v1.2.0-preview dépend de ce package
    FALSE, dernière version stable ne dépend pas de ce package

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

    Notes

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

  • 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é a des mises à jour récentes et un historique de version long. Les packages négligés ont quelques mises à jour depuis longtemps.

    Capture d’écran montrant la liste Versions.

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

Capture d’écran montrant la colonne droite de la page du package.

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

  • Sélectionnez Le référentiel source pour accéder au référentiel de code source Git pour le package. De nombreux auteurs conservent 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 du package est un bon indicateur du nombre de développeurs qui sont activement impliqués.

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

  • Sélectionnez l’un des propriétaires de packages sous Propriétaires pour afficher les autres packages qu’ils ont publiés. Les propriétaires avec plusieurs packages sont plus susceptibles de continuer à prendre en charge leur travail. Sélectionnez Contacter les propriétaires en regard des 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 des informations de licence. Pour maintenir la compatibilité descendante dans ces cas, l’URL de licence pointe vers ce document sur la façon de récupérer les informations de licence.

Si la sélection de l’URL de licence pour un package vous amène à cette page, elle implique que le package contient un fichier de licence et :

  • Vous êtes connecté à un flux qui ne sait pas comment interpréter et surfacer les informations de licence au client, ou
  • Vous utilisez un client qui ne sait pas comment interpréter et lire les informations de licence fournies par le flux, ou
  • 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 <license> balise, 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 plus d’informations sur msBuild équivalent à la définition de la licence dans .nuspec, consultez Empaquetage d’une expression de licence ou d’un fichier de licence.

Étapes suivantes