Partager via

Créer un package à l’aide de l’interface CLI nuget.exe

Peu importe ce que fait votre package ou le code qu’il contient, vous utilisez l’un des outils d’interface de ligne de commande (CLI), soit nuget.exedotnet.exepour empaqueter cette fonctionnalité dans un composant qui peut être partagé avec et utilisé par d’autres développeurs. Pour installer les outils de l’interface CLI NuGet, consultez Installer les outils clients NuGet. Visual Studio n'inclut pas automatiquement un outil CLI.

Techniquement, un package NuGet est un fichier ZIP renommé pour avoir l’extension .nupkg et dont le contenu correspond à certaines conventions. Cet article décrit le processus détaillé de création d’un package qui répond à ces conventions.

L’empaquetage commence par le code compilé (assemblys), les symboles et d’autres fichiers que vous souhaitez remettre en tant que package. Pour obtenir une vue d’ensemble du processus d’empaquetage, consultez le flux de travail de création de package. Ce processus est indépendant de la compilation ou de la génération des fichiers qui entrent dans le package. Toutefois, vous pouvez tirer parti d’informations dans un fichier projet pour conserver les assemblys et packages compilés synchronisés.

Important

Cet article s’applique aux projets non de style SDK, généralement des projets autres que .NET Core et .NET Projets Standard qui utilisent Visual Studio 2017 et versions ultérieures et NuGet 4.0+.

Déterminer les assemblies à packager

La plupart des packages à usage général contiennent un ou plusieurs assemblys que d’autres développeurs peuvent utiliser dans leurs propres projets.

En général, il est préférable d’avoir un assembly par package NuGet, à condition que chaque assembly soit utile indépendamment. Par exemple, considérez les cas suivants qui impliquent un assembly appelé Utilities.dll qui dépend d’un assembly appelé Parser.dll:

  • Si Parser.dll est utile seul, créez un package pour Utilities.dll et un pour Parser.dll. Cela permet aux développeurs d’utiliser Parser.dll indépendamment de Utilities.dll.

  • Si Parser.dll contient du code utilisé uniquement par Utilities.dll, il est recommandé de conserver Parser.dll dans le même package. En général, si votre bibliothèque est composée de plusieurs assemblys qui ne sont pas utiles indépendamment, il est judicieux de les combiner en un seul package.

  • Si Utilities.dll dépend également de Utilities.resources.dll, et Utilities.resources.dll n’est pas utile seul, placez les deux dans le même package.

Les ressources, telles que l’assembly Utilities.resources.dll dans l’exemple précédent, sont un cas particulier. Lorsqu’un package est installé dans un projet, NuGet ajoute automatiquement des références d’assembly aux DLL du package, à l’exclusion de celles nommées .resources.dll, car elles sont supposées être des assemblys satellites localisés. Pour plus d’informations sur les versions localisées d’une bibliothèque, consultez Création de packages NuGet localisés. Pour cette raison, évitez d’utiliser .resources.dll pour les fichiers qui contiennent du code de package essentiel.

Si votre bibliothèque contient des assemblys COM (Component Object Model), suivez les instructions supplémentaires dans Créer des packages NuGet qui contiennent des assemblys COM Interop.

Rôle et structure du fichier .nuspec

Lorsque vous savez quels fichiers vous souhaitez empaqueter, l’étape suivante consiste à créer un manifeste de package dans un fichier XML .nuspec .

Manifeste :

  • Décrit le contenu du package et est lui-même inclus dans le package.
  • Pilote la création du package et indique à NuGet comment installer le package dans un projet. Par exemple, le manifeste identifie d’autres dépendances de package afin que NuGet puisse également installer ces dépendances lorsque le package principal est installé.
  • Contient les propriétés obligatoires et facultatives, comme décrit dans le reste de cette section. Pour plus d’informations, y compris d’autres propriétés non mentionnées ici, consultez la référence .nuspec.

Les propriétés suivantes sont requises dans le manifeste :

  • Identificateur de package, qui doit être unique dans la galerie qui héberge le package
  • Numéro de version spécifique sous la forme Major.Minor.Patch[-Suffix], où -Suffix identifie les versions préliminaires
  • Titre du package tel qu’il doit apparaître sur l’hôte (comme nuget.org)
  • Informations sur l’auteur
  • Description longue du package

Les propriétés suivantes sont des propriétés facultatives courantes :

  • Notes de publication.
  • Informations sur le droit d’auteur.
  • Brève description de l’interface utilisateur Gestionnaire de package dans Visual Studio.
  • ID de locale.
  • URL du projet.
  • Licence en tant qu’expression ou fichier. La licenseUrl propriété est obsolète. Utilisez l’élément de métadonnées nuspec license à la place.
  • Un fichier read-me.
  • Fichier d’icône. La iconUrl propriété est obsolète. Utilisez plutôt l’élément de métadonnées nuspec.
  • Listes de dépendances et de références.
  • Balises qui aident à effectuer des recherches dans la galerie.

Le code suivant est un fichier .nuspec classique (mais fictif), avec des commentaires qui décrivent les propriétés :

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- An identifier that must be unique within the hosting gallery -->
        <id>Contoso.Utility.UsefulStuff</id>

        <!-- A package version number that's used when resolving dependencies -->
        <version>1.8.3</version>

        <!-- A comma-separated list of package authors that sometimes appears directly on the gallery -->
        <authors>Dejana Tesic, Rajeev Dey</authors>

        <!-- A project URL that provides a link for the gallery -->
        <projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>

        <!-- License information that's displayed on the gallery -->
        <license type="expression">Apache-2.0</license>
        
        <!-- The location of a read-me file that's displayed in the Visual Studio Package Manager UI -->
        <readme>readme.md</readme>

        <!-- An icon that's used in the Visual Studio Package Manager UI -->
        <icon>icon.png</icon>

        <!-- 
            A property that when true, prompts the user to accept the license when
            installing the package
        -->
        <requireLicenseAcceptance>false</requireLicenseAcceptance>

        <!-- Detailed information about a particular release -->
        <releaseNotes>Bug fixes and performance improvements</releaseNotes>

        <!-- 
            A description that can be used in the Package Manager UI. The
            nuget.org gallery uses information you add in the portal. 
        -->
        <description>Core utility functions for web applications</description>

        <!-- Copyright information -->
        <copyright>Copyright ©2026 Contoso Corporation</copyright>

        <!-- Tags that appear in the gallery and can be used for tag searches -->
        <tags>web utility http json url parsing</tags>

        <!-- Dependencies that are automatically installed when the package is installed -->
        <dependencies>
            <dependency id="Newtonsoft.Json" version="9.0" />
        </dependencies>
    </metadata>

    <!-- A read-me Markdown file that's displayed in the Package Manager UI -->
    <files>
        <file src="readme.md" target="" />
        <file src="icon.png" target="" />
    </files>
</package>

Pour plus d’informations sur la déclaration de dépendances et la spécification des numéros de version, consultez packages.config et le contrôle de version du package. Vous pouvez également utiliser les attributs include et exclude de l'élément dependency pour spécifier les ressources de dépendance que vous souhaitez inclure ou exclure dans le paquet. Pour plus d’informations, consultez l’élément .nuspec Reference - Dependencies.

Étant donné que le manifeste est inclus dans le package créé à partir de celui-ci, vous pouvez trouver des exemples en examinant les packages existants. Une bonne source est le dossier global-packages sur votre ordinateur. Pour trouver son emplacement, utilisez la commande suivante :

nuget locals -list global-packages

Une fois que vous connaissez l’emplacement du dossier global-packages , procédez comme suit pour rechercher un fichier manifeste :

  1. Accédez au dossier global-packages .
  2. Dans ce dossier, accédez au sous-dossier de n’importe quel package, puis accédez à un sous-dossier pour n’importe quelle version de ce package.
  3. Dans le sous-dossier de version, effectuez une copie du fichier .nupkg et modifiez l’extension de la copie en zip.
  4. Ouvrez le fichier .zip et examinez le fichier .nuspec dans celui-ci.

Note

Lorsque vous créez un fichier .nuspec à partir d’un projet Visual Studio, le manifeste contient des jetons remplacés par des informations du projet lors de la génération du package. Pour plus d’informations, consultez Createz le fichier .nuspec à partir d’un projet Visual Studio.

Créer le fichier .nuspec

La création d’un manifeste complet commence généralement par un fichier .nuspec de base généré par l’une des méthodes suivantes :

Vous modifiez ensuite le fichier manuellement afin qu’il décrit le contenu exact souhaité dans le package final.

Important

Les fichiers .nuspec générés contiennent des espaces réservés que vous devez modifier avant de créer le package à l’aide de la nuget pack commande. Cette commande échoue si le fichier .nuspec contient des espaces réservés.

À partir d’un répertoire de travail basé sur une convention

Étant donné qu’un package NuGet est un fichier ZIP renommé avec l’extension .nupkg , il est souvent plus simple de créer la structure de dossiers souhaitée sur votre système de fichiers local, puis de créer le fichier .nuspec directement à partir de cette structure. La nuget pack commande ajoute ensuite automatiquement tous les fichiers de cette structure de dossiers, mais elle exclut tous les dossiers qui commencent par une période. Vous pouvez donc conserver des fichiers privés dans la même structure.

L’avantage de cette approche est que vous n’avez pas besoin de spécifier dans le manifeste les fichiers que vous souhaitez inclure dans le package, comme expliqué plus loin dans cette section. Au lieu de cela, vous pouvez faire en sorte que votre processus de génération produise la structure de dossiers exacte qui sera incluse dans le paquet. Vous pouvez également inclure facilement d’autres fichiers qui peuvent ne pas faire partie d’un projet sinon :

  • Contenu et code source à injecter dans le projet cible
  • Scripts PowerShell
  • Transformations apportées aux fichiers de configuration et de code source existants dans un projet

Les dossiers s’alignent sur les conventions suivantes :

Dossier Contenu Action lors de l’installation du package
(racine) Manifeste de paquet, dossiers racine et éventuellement, un fichier README au format Markdown et une image d'icône Ce dossier est utilisé comme point de départ pour les sous-dossiers standardisés, tels que lib et build.
lib/<tfm> Assembly (.dll), documentation (.xml) et fichier de symboles (.pdb) pour l'identifiant de framework cible (TFM) donné Les assemblies sont ajoutés en tant que références pour le temps de compilation et le temps d'exécution. Les fichiers .xml et .pdb sont copiés dans les dossiers de projet. Pour plus d’informations sur la création de sous-dossiers spécifiques à la cible du framework, consultez Supporter plusieurs versions .NET.
ref/<tfm> Fichiers d'assembly (.dll) et symboles (.pdb) pour le TFM donné Les assemblages sont ajoutés en tant que références uniquement pour le temps de compilation. Rien n’est copié dans le dossier bin de projet.
Runtimes Assemblage spécifique à l’architecture (.dll), symboles (.pdb) et ressource native (.pri) Les assemblies sont ajoutées en tant que références uniquement pour l'environnement d'exécution. D’autres fichiers sont copiés dans les dossiers de projet. Il doit toujours y avoir un assembly spécifique (TFM) AnyCPU dans le dossier /ref/<tfm> afin de fournir l’assembly de compilation correspondant. Consultez Supporter plusieurs versions .NET.
contenu Fichiers arbitraires Le contenu est copié à la racine du projet. Considérez le dossier de contenu comme la racine de l’application cible qui consomme finalement le package. Pour que le package ajoute une image dans le dossier /images de l’application, placez-la dans le dossier contenu/images du package.
Construire (3.x+) Microsoft Build Engine (MSBuild) .targets et .props fichiers Ces fichiers sont automatiquement insérés dans le projet.
buildMultiTargeting (4.0+) Fichiers MSBuild .targets et .props pour ciblage multicadre Ces fichiers sont automatiquement insérés dans le projet.
buildTransitive (5.0+) Fichiers .targets et .props MSBuild qui circulent de manière transitive vers n’importe quel projet consommant Ces fichiers sont automatiquement insérés dans le projet. Consultez la page des fonctionnalités .
Outils Scripts et programmes PowerShell accessibles à partir de la console Gestionnaire de package Le dossier tools est ajouté à la variable d’environnement PATH pour la console Gestionnaire de package uniquement. Elle n’est pas ajoutée à la PATH valeur utilisée par MSBuild lors de la génération du projet.

Étant donné que votre structure de dossiers peut contenir des assemblys pour de nombreux frameworks cibles, cette méthode est nécessaire lorsque vous créez des packages qui prennent en charge plusieurs frameworks.

Lorsque vous disposez de la structure de dossiers souhaitée, exécutez la commande suivante dans ce dossier pour créer le fichier .nuspec :

nuget spec

Le fichier .nuspec généré ne contient aucune référence explicite aux fichiers de la structure de dossiers. NuGet inclut automatiquement tous les fichiers lors de la création du package. Toutefois, vous devez toujours modifier les valeurs d’espace réservé dans d’autres parties du manifeste.

À partir d’une DLL d’assemblage

Dans le cas de base de la création d’un package à partir d’un assembly, vous pouvez générer un fichier .nuspec à partir des métadonnées de l’assembly à l’aide de la commande suivante :

nuget spec <assembly-name>.dll

L’utilisation de ce formulaire remplace quelques espaces réservés dans le manifeste par des valeurs spécifiques de l’assembly. Par exemple, la <id> propriété est définie sur le nom de l’assembly et <version> est définie sur la version de l’assembly. Toutefois, les autres propriétés du manifeste n’ont pas de valeurs correspondantes dans l’assembly. Après avoir exécuté la commande, ces propriétés contiennent toujours des espaces réservés.

À partir d’un projet Visual Studio

La création d’un fichier .nuspec à partir d’un fichier .csproj ou .vbproj est pratique, car les autres packages installés dans le projet sont automatiquement référencés en tant que dépendances. Pour créer un manifeste à partir d’un fichier projet, utilisez la commande suivante dans le dossier qui contient le fichier projet :

# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget spec

Le fichier project-name.nuspec< résultant> contient des jetons remplacés au moment de l’empaquetage par des valeurs du projet, y compris des références à d’autres packages déjà installés.

Si vous avez des dépendances de package à inclure dans .nuspec, utilisez nuget packplutôt . Obtenez ensuite le fichier .nuspec à partir du fichier .nupkg généré. Par exemple, utilisez la commande suivante :

# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget pack myproject.csproj

Un jeton est délimité par les symboles $ de chaque côté de la propriété du projet. Par exemple, la <id> valeur d’un manifeste généré de cette façon ressemble généralement à la ligne suivante :

<id>$id$</id>

Ce jeton est remplacé par la AssemblyName valeur du fichier projet au moment de l’emballage. Pour obtenir le mappage exact des valeurs de projet aux jetons de fichier .nuspec , consultez Jetons de remplacement.

Les jetons vous dispensent de mettre à jour des valeurs cruciales comme le numéro de version dans le fichier .nuspec lorsque vous mettez à jour le projet. Toutefois, vous pouvez également remplacer les jetons par des valeurs littérales.

Plusieurs options d’empaquetage supplémentaires sont disponibles lorsque vous travaillez à partir d’un projet Visual Studio, comme décrit dans Exécuter le pack nuget pour générer le fichier .nupkg plus loin dans cet article.

Packages au niveau de la solution

NuGet 2.x uniquement. Non disponible dans NuGet 3.0+.

NuGet 2.x prend en charge la notion d'un package de niveau solution qui installe des outils ou des commandes supplémentaires pour la console Gestionnaire de package (le contenu de l'tools dossier), mais n'ajoute pas de références, de contenu ou de personnalisations de build à des projets de la solution. Ces packages ne contiennent aucun fichier dans leurs dossiers de bibliothèque, de contenu ou de build directs, et aucune de leurs dépendances n’a de fichiers dans leurs dossiers de bibliothèque, de contenu ou de build respectifs.

NuGet effectue le suivi des packages installés au niveau de la solution dans un fichier packages.config dans le dossier .nuget , plutôt que dans le fichier packages.config du projet.

À partir d’un nouveau fichier avec des valeurs par défaut

La commande suivante crée un manifeste par défaut avec des espaces réservés, ce qui vous permet de commencer par la structure de fichiers appropriée :

nuget spec [<package-name>]

Si vous omettez <package-name>, le fichier résultant est nommé Package.nuspec. Si vous fournissez un nom tel que Contoso.Utility.UsefulStuff, le fichier est nommé Contoso.Utility.UsefulStuff.nuspec.

Le fichier .nuspec résultant contient des espaces réservés pour les valeurs telles que projectUrl. Avant d’utiliser le fichier pour créer le fichier .nupkg final, remplacez les espaces réservés par les valeurs appropriées.

Choisir un identificateur de package unique et définir le numéro de version

L’identificateur de package (<id> élément) et le numéro de version (<version> élément) sont les deux valeurs les plus importantes du manifeste, car ils identifient de manière unique le code exact contenu dans le package.

Bonnes pratiques pour l’identificateur de package

  • Unicité : l’identificateur doit être unique dans la galerie qui héberge le package, tel que nuget.org. Avant de décider d’un identificateur, recherchez la galerie applicable pour vérifier si le nom est déjà utilisé. Pour éviter les conflits, un bon modèle consiste à utiliser le nom de votre entreprise comme première partie de l’identificateur, par Contosoexemple .
  • Namespace-like names : Suivez un modèle similaire aux espaces de noms dans .NET, en utilisant la notation par points au lieu de traits d’union. Par exemple, utilisez Contoso.Utility.UsefulStuff plutôt que Contoso-Utility-UsefulStuff ou Contoso_Utility_UsefulStuff. Les consommateurs trouvent également utile lorsque l’identificateur de paquet correspond aux espaces de noms utilisés dans le code.
  • Exemples de packages : si vous produisez un package d’exemple de code qui montre comment utiliser un autre package, attacher .Sample en tant que suffixe à l’identificateur, comme dans Contoso.Utility.UsefulStuff.Sample. Un exemple de package de ce type a une dépendance sur le package qu’il montre comment utiliser. Lorsque vous créez un exemple de package, utilisez la méthode de répertoire de travail basée sur la convention décrite précédemment. Dans le dossier de contenu , organisez l’exemple de code dans un dossier appelé \Samples\<identifier>, comme dans \Samples\Contoso.Utility.UsefulStuff.Sample.

Meilleures pratiques pour la version du package

  • En général, définissez la version du package pour qu’elle corresponde à la bibliothèque. Ces conseils sont recommandés, mais pas strictement requis. Cette pratique est simple lorsque vous limitez un package à un seul assembly, comme décrit précédemment dans Déterminer les assemblys à empaqueter. En général, n’oubliez pas que NuGet lui-même traite des versions de package lors de la résolution des dépendances, et non des versions d’assembly.
  • Lorsque vous utilisez un schéma de version non standard, tenez compte des règles de contrôle de version NuGet, comme expliqué dans le contrôle de version du package.

Pour d’autres ressources utiles pour comprendre le contrôle de version, consultez la série de billets de blog suivants :

Ajouter un fichier Lisez-moi et d’autres fichiers

Pour spécifier directement des fichiers à inclure dans le package, utilisez le <files> nœud dans le fichier .nuspec , qui suit la <metadata> balise :

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- ... -->
    </metadata>
    <files>
        <!-- Add files from an arbitrary folder that's not necessarily in the project. -->
        <file src="..\..\SomeRoot\**\*.*" target="" />
    </files>
</package>

Conseil / Astuce

Lorsque vous utilisez l’approche du répertoire de travail basé sur la convention, vous pouvez placer le fichier readme.md dans la racine du package et d’autres contenus dans le dossier de contenu . Aucun élément <file> n'est nécessaire dans le manifeste.

Pour inclure un fichier en lecture-moi dans le package, utilisez l’élément readme de métadonnées pour spécifier le chemin d’accès cible au fichier en lecture-moi. Utilisez également un élément de métadonnée file pour spécifier le chemin d’accès source et le dossier cible du fichier lisez-moi. Pour plus d’informations, consultez readme.

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- ... -->
        <readme>docs\readme.md</readme>
        <!-- ... -->
    </metadata>
    <files>
        <!-- Add a read-me file. -->
        <file src="..\readme.md" target="docs\" />
    </files>
</package>

Visual Studio affiche le contenu du fichier Lisez-moi dans l'interface utilisateur du gestionnaire de packages. Par exemple, la capture d’écran suivante montre le fichier lisez-moi pour le paquet HtmlAgilityPack :

Screenshot de l’interface utilisateur Visual Studio Gestionnaire de package qui affiche un volet d’informations de package. L’onglet README décrit les capacités d’analyse HTML du package.

Note

Si vous incluez un nœud vide <files> dans le fichier .nuspec , NuGet inclut le contenu du dossier lib dans le package, mais aucun autre contenu.

Inclure des propriétés et des cibles MSBuild dans un package

Dans certains cas, vous pouvez ajouter des cibles ou des propriétés de build personnalisées à des projets qui consomment votre package, comme l’exécution d’un outil personnalisé ou d’un processus pendant la génération. Pour plus d’informations sur les cibles et propriétés de build personnalisées, consultez MSBuild .props et .targets dans un package.

Créez <package-id>.targets ou <package-id>.props, tels que Contoso.Utility.UsefulStuff.targets, dans la structure de répertoire 'build' du projet.

Ensuite, dans le fichier .nuspec, reportez-vous à ces fichiers dans le nœud <files> :

<?xml version="1.0"?>
<package >
    <metadata minClientVersion="2.5">
    <!-- ... -->
    </metadata>
    <files>
        <!-- In the package build folder, include everything that's in the local build folder. -->
        <file src="build\**" target="build" />

        <!-- Other files -->
        <!-- ... -->
    </files>
</package>

Lorsque des packages sont ajoutés à un projet, NuGet inclut automatiquement ces propriétés et cibles.

Exécuter le pack nuget pour générer le fichier .nupkg

Lorsque vous utilisez un assembly ou le répertoire de travail basé sur la convention, créez un package en exécutant nuget pack votre fichier .nuspec . Dans la commande suivante, remplacez <project-name> par le nom de votre projet :

nuget pack <project-name>.nuspec

Lorsque vous utilisez un projet Visual Studio, exécutez nuget pack avec votre fichier projet. Cette commande charge automatiquement le fichier .nuspec du projet et remplace tous les jetons qu’il contient par les valeurs correspondantes dans le fichier projet :

nuget pack <project-name>.csproj

Note

Pour le remplacement du jeton, vous devez utiliser directement le fichier projet, car le projet est la source des valeurs de jeton. Le remplacement de jeton ne réussit pas si vous utilisez nuget pack avec un fichier .nuspec.

Dans tous les cas, nuget pack exclut les dossiers qui commencent par un point, tels que .git ou .hg.

NuGet indique s’il existe des erreurs dans le fichier .nuspec qui ont besoin de corriger, telles que les valeurs d’espace réservé dans le manifeste qui doivent être mises à jour.

Après avoir réussi nuget pack, vous disposez d’un fichier .nupkg que vous pouvez publier dans une galerie appropriée, comme décrit dans Publication des packages NuGet.

Conseil / Astuce

Un moyen utile d’examiner un package après sa création consiste à l’ouvrir dans l’outil Explorateur de packages . Cet outil vous donne une vue graphique du contenu du package et de son manifeste. Vous pouvez également renommer le fichier .nupkg obtenu en fichier .zip et explorer son contenu directement.

Options supplémentaires

Vous pouvez utiliser différents commutateurs de ligne de commande avec nuget pack pour exclure des fichiers, remplacer le numéro de version dans le manifeste et modifier le dossier de sortie, entre autres fonctionnalités. Pour obtenir une liste complète, consultez la commande pack (Cli NuGet) .

Les options suivantes sont quelques-unes courantes avec les projets Visual Studio :

  • Projets référencés : si le projet fait référence à d’autres projets, vous pouvez ajouter les projets référencés dans le cadre du package, ou en tant que dépendances, à l’aide de l’option -IncludeReferencedProjects :

    nuget pack MyProject.csproj -IncludeReferencedProjects

    Ce processus d’inclusion est récursif. Par exemple, si MyProject.csproj fait référence à des projets B et C, et que ces projets font référence à D, E et F, les fichiers de B, C, D, E et F sont inclus dans le package.

    Si un projet référencé inclut un fichier .nuspec propre, NuGet ajoute ce projet référencé comme dépendance à la place. Vous devez empaqueter et publier ce projet séparément.

  • Configuration de build : Par défaut, NuGet utilise la configuration de build par défaut définie dans le fichier projet, généralement Debug. Pour packer des fichiers à partir d'une autre configuration de build, utilisez par exemple l'option -properties avec la configuration :

    nuget pack MyProject.csproj -properties Configuration=Release

  • Symboles : pour inclure des symboles qui permettent aux consommateurs de parcourir votre code de package dans le débogueur, utilisez les options -Symbols et -SymbolPackageFormat. Pour l’option -SymbolPackageFormat , spécifiez un format de snupkg:

    nuget pack MyProject.csproj -symbols -SymbolPackageFormat snupkg

Installation du package de test

Avant de publier un package, vous souhaitez généralement tester le processus d’installation du package dans un projet. Un test permet de s’assurer que tous les fichiers nécessaires se retrouvent au bon endroit dans le projet.

Vous pouvez tester manuellement les installations dans Visual Studio ou sur la ligne de commande à l’aide des étapes d’installation standard de package.

Pour les tests automatisés, vous pouvez utiliser le processus de base suivant :

  1. Copiez le fichier .nupkg dans un dossier local.
  2. Ajoutez le dossier à vos sources de package à l’aide de la nuget sources add -name <name> -source <path> commande. Pour plus d’informations, consultez la commande sources (cli NuGet). Vous devez définir cette source locale une seule fois sur un ordinateur donné.
  3. Installez le paquet à partir de cette source à l’aide de nuget install <package-ID> -source <name>. Dans cette commande, <name> doit correspondre au nom de la source que vous utilisez dans la nuget sources commande. La spécification de la source indique à NuGet d’installer le package à partir de cette source seule.
  4. Examinez votre système de fichiers pour vérifier que les fichiers sont installés correctement.

Contenu connexe

Après avoir créé un package, qui est un fichier .nupkg , vous pouvez le publier dans la galerie de votre choix. Pour plus d’informations, consultez Publier des packages NuGet.

Vous pouvez également étendre les fonctionnalités de votre package ou prendre en charge d’autres scénarios. Pour plus d’informations, consultez les articles suivants :

Pour connaître d’autres types de packages, consultez les articles suivants :

  • Last updated on