Pour parcourir les questions fréquemment posées à propos de NuGet.org, notamment les questions relatives aux comptes NuGet.org, consultez Questions fréquentes (FAQ) sur NuGet.org.
Toutes les informations relatives à l’interface utilisateur et aux outils en ligne de commande sont disponibles dans le guide d’installation.
L’outil en ligne de commande, nuget.exe
les builds et les exécutions s’exécutent généralement sous Windows. NuGet peut s’exécuter sur des systèmes d’exploitation Unix à l’aide mono
de , mais il n’est pas officiellement pris en charge par la stratégie de support de NuGet.
Mono a transféré la propriété à Wine et n’est plus maintenu par Microsoft.
Comment puis-je déterminer ce que contient un package et s’il est stable et utile pour mon application ?
La principale source d’apprentissage sur un package est sa page d’annonce sur nuget.org (ou sur un autre flux privé). Chaque page de package sur nuget.org inclut une description du package, son historique des versions et les statistiques d’utilisation. La section Info sur la page de package contient également un lien vers le site web du projet où vous trouvez généralement de nombreux exemples et autres documentations pour vous aider à découvrir comment le package est utilisé.
Pour plus d’informations, consultez Recherche et sélection des packages.
- Visual Studio sur Windows prend en charge l’interface utilisateur du Gestionnaire de package et la console du Gestionnaire de package.
- Visual Studio pour Mac offre des fonctionnalités NuGet intégrées, comme décrit dans Inclusion d’un package NuGet dans votre projet.
- Visual Studio Code (toutes les plateformes) n’a pas d’intégration directe de NuGet. Utilisez l’interface de ligne de commande NuGet ou l’interface de ligne de commande dotnet.
- Azure DevOps fournit une étape de la génération pour restaurer des packages NuGet. Vous pouvez également héberger des flux de packages NuGet privés sur Azure DevOps.
Dans Visual Studio, utilisez la commande Aide > À propos de Microsoft Visual Studio et examinez la version affichée en regard de Gestionnaire de package NuGet.
Vous pouvez également lancer la console du Gestionnaire de package (Outils > Gestionnaire de package NuGet > Console du Gestionnaire de package), puis entrer $host
pour afficher des informations sur NuGet, notamment la version.
En règle générale, NuGet fonctionne pour les langages .NET et est conçu pour intégrer les bibliothèques .NET dans un projet. Comme il prend également en charge MSBuild et Visual Studio Automation dans certains types de projets, il prend aussi en charge d’autres projets et langages à des degrés divers.
La version la plus récente de NuGet prend en charge C#, Visual Basic, F#, WiX et Q#.
NuGet prend totalement en charge de nombreux modèles de projet tels que Windows, Web, Cloud, SharePoint, Wix, etc.
Accédez à l’onglet Mises à jour dans l’interface utilisateur du Gestionnaire de package et sélectionnez Mettre à jour tout, ou utilisez la commande Update-Package
à partir de la console du Gestionnaire de package.
Pour mettre à jour le modèle lui-même, vous devez mettre à jour manuellement le dépôt du modèle. Consultez le blog de Xavier Decoster à ce sujet. Notez que cette opération est effectuée à vos risques et périls, étant donné que les mises à jour manuelles peuvent endommager le modèle si les dernières versions de toutes les dépendances ne sont pas compatibles entre elles.
Oui, NuGet fonctionne directement à partir de la ligne de commande. Consultez le guide d’installation et les informations de référence sur l’interface de ligne de commande.
Consultez le guide d’installation. Pour vérifier la version actuelle installée de l'outil, utilisez nuget help
.
Vous êtes autorisé à redistribuer nuget.exe selon les termes de la licence du MIT. Vous êtes responsable de la mise à jour et de la maintenance de toutes les copies de nuget.exe que vous souhaitez redistribuer.
Oui, vous pouvez ajouter des commandes personnalisées à nuget.exe
, comme le décrit le billet de blog de Rob Reynold disponible sur Archive.org.
L’objet de niveau supérieur dans le modèle objet automation Visual Studio est appelé objet DTE (Development Tools Environment). La console le fournit par le biais d’une variable nommée $DTE
. Pour plus d’informations, consultez Vue d’ensemble du modèle Automation dans la documentation de l’extensibilité de Visual Studio.
J’essaie de caster la variable $DTE en type DTE2, mais j’obtiens une erreur indiquant qu’il est impossible de convertir la valeur « EnvDTE.DTEClass » du type « EnvDTE.DTEClass » en type « EnvDTE80.DTE2 ». Quel est le problème ?
Il s’agit d’un problème connu lié à la façon dont PowerShell interagit avec un objet COM. Essayez ce qui suit :
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Get-Interface
est une fonction d’assistance ajoutée par l’hôte PowerShell NuGet.
Consultez Création et publication d’un package.
Plusieurs versions de ma bibliothèque ciblent des versions différentes du .NET Framework. Comment créer un package unique qui prend en charge ce cas de figure ?
Consultez la vue d’ensemble de l’hébergement des packages.
Consultez Bulk publishing NuGet packages (Publication de packages NuGet en bloc) (jeffhandly.com).
Oui, consultez le billet de Blog de Scott Hanselman How to access NuGet when nuget.org is down (or you're on a plane) (hanselman.com).
Définissez le paramètre repositoryPath
dans Nuget.Config
en utilisant nuget config -set repositoryPath=<path>
.
Définissez disableSourceControlIntegration
dans Nuget.Config
sur true
. Cette clé, qui fonctionne au niveau de la solution, doit être ajoutée au fichier $(Solutiondir)\.nuget\Nuget.Config
. L’activation de la restauration des packages à partir de Visual Studio crée ce fichier automatiquement.
Quand j’installe un package local avec des dépendances distantes, j’obtiens un message indiquant qu’il est impossible de résoudre une erreur de dépendance. Pourquoi ?
Vous devez sélectionner la source Tous durant l’installation d’un package local dans le projet. Cette option regroupe tous les flux au lieu d’en utiliser un seul. Cette erreur est liée au fait que les utilisateurs d’un dépôt local souhaitent souvent éviter d’installer accidentellement un package distant en raison de stratégies d’entreprise.
J’ai plusieurs projets dans le même dossier ; comment utiliser des fichiers packages.config distincts pour chaque projet ?
Dans la plupart des projets où des projets distincts se trouvent dans des dossiers séparés, ce n’est pas un problème, car NuGet identifie les fichiers packages.config
dans chaque projet. Si vous utilisez NuGet 3.3+ et que plusieurs projets se trouvent dans le même dossier, vous pouvez insérer le nom du projet dans les noms de fichier packages.config
et utiliser le modèle packages.{project-name}.config
; NuGet utilise alors ce fichier.
Cela n’est pas un problème si vous utilisez PackageReference, car chaque fichier de projet contient sa propre liste de dépendances.
- Ajoutez
https://api.nuget.org/v3/index.json
à votre liste de sources, ou - Supprimez
%appdata%\.nuget\NuGet.Config
(Windows) ou~/.nuget/NuGet/NuGet.Config
(Mac/Linux) et laissez NuGet le recréer.
J’ai migré vers PackageReference, pourquoi ma build échoue-t-elle : « Ce projet fait référence à des packages NuGet manquants sur cet ordinateur » ?
Dans les projets packages.config, lorsqu’un package avec des propriétés ou des cibles build
a été installé, NuGet ajoute une cible EnsureNuGetPackageBuildImports
pour vérifier que le contenu msbuild des packages a été importé avant la génération de la version.
Si le fichier target
a été modifié manuellement, NuGet peut ne pas être en mesure de détecter qu’il doit être supprimé lors de la migration.
Si votre projet est PackageReference
et que vous disposez toujours de cette cible dans le fichier projet, vous pouvez la supprimer en toute sécurité.