dotnet build

Cet article s’applique à : ✔️ SDK .NET Core 6 et versions ultérieures

Nom

dotnet build - Génère un projet, une solution ou une application basée sur des fichiers et toutes ses dépendances.

Synopsis

dotnet build [<PROJECT>|<SOLUTION>|<FILE>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]  [-bl|--binaryLogger:<FILE>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--no-dependencies] [--no-incremental] [--no-restore] [--nologo]
    [--no-self-contained] [-o|--output <OUTPUT_DIRECTORY>] [--os <OS>]
    [-p|--property:<PROPERTYNAME>=<VALUE>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained] [--source <SOURCE>]
    [--tl:[auto|on|off]] [ --ucr|--use-current-runtime]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet build -h|--help

Description

La dotnet build commande génère le projet, la solution ou l’application basée sur des fichiers et ses dépendances dans un ensemble de fichiers binaires. Les composants binaires incluent le code du projet dans des fichiers de langage intermédiaire (IL) .dll. Selon le type de projet et les paramètres, d'autres fichiers peuvent être inclus, par exemple :

• Exécutable qui peut être utilisé pour exécuter l’application.
• Fichiers de symboles .pdb utilisés pour le débogage.
• Fichier .deps.json répertoriant les dépendances de l'application ou de la bibliothèque.
• Fichier .runtimeconfig.json spécifiant le runtime partagé et sa version pour une application.
• Autres bibliothèques dont dépend le projet (via des références de projet ou des références de package NuGet).

Pour les projets exécutables ciblant .NET Core 3.0 et versions ultérieures, les dépendances de bibliothèque sont copiées dans le dossier de sortie. Cela signifie que s’il n’existe aucune autre logique spécifique à la publication (par exemple, des projets web), la sortie de build doit être déployable.

Restauration implicite

La génération requiert le fichier project.assets.json qui répertorie les dépendances de votre application. Le fichier est créé quand la commande dotnet restore est exécutée. Si le fichier de ressources est absent, les outils ne peuvent pas résoudre les assemblys de référence, ce qui entraîne des erreurs.

Vous n’avez pas besoin d’exécuter dotnet restore, car il est exécuté implicitement par toutes les commandes qui nécessitent une restauration pour se produire, comme dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish et dotnet pack. Pour désactiver la restauration implicite, utilisez l’option --no-restore .

La commande dotnet restore est toujours utile dans certains scénarios où la restauration explicite est logique, comme les builds d’intégration continue dans Azure DevOps Services ou dans les systèmes de génération qui doivent contrôler explicitement le moment où la restauration se produit.

Pour plus d’informations sur la gestion des flux NuGet, consultez la documentation dotnet restore.

Cette commande prend en charge les options de dotnet restore quand elles sont transférées sous leur forme longue (par exemple --source). Les options sous forme abrégée, comme -s, ne sont pas prises en charge.

Exécutable ou sortie de la bibliothèque

La possibilité d’exécuter le projet ou non est déterminée par la propriété <OutputType> dans le fichier projet. L’exemple suivant illustre un projet qui génère du code exécutable :

<PropertyGroup>
  <OutputType>Exe</OutputType>
</PropertyGroup>

Pour produire une bibliothèque, omettez la propriété <OutputType> ou définissez sa valeur sur Library. La DLL IL d’une bibliothèque ne contient pas de points d’entrée et ne peut pas être exécutée.

MSBuild

dotnet build utilise MSBuild pour générer le projet, la solution ou l’application basée sur des fichiers. Il prend en charge les builds parallèles et incrémentielles. Pour plus d’informations, consultez l’article Incremental Builds (Générations incrémentielles) .

En plus de ses options, la commande dotnet build accepte des options MSBuild, comme -p pour définir des propriétés ou -l pour définir un enregistreur d’événements. Pour plus d’informations sur ces options, consultez Informations de référence sur la ligne de commande MSBuild. Ou vous pouvez également utiliser la commande dotnet msbuild.

Notes

Lorsque dotnet build est exécuté automatiquement par dotnet run, les arguments comme -property:property=value ne sont pas respectés.

L’exécution de dotnet build équivaut à l’exécution de dotnet msbuild -restore ; toutefois, les informations détaillées par défaut de la sortie sont différentes.

Téléchargements du manifeste de charge de travail

Lorsque vous exécutez cette commande, elle lance en arrière-plan un téléchargement asynchrone des manifestes publicitaires des charges de travail. Si le téléchargement est toujours en cours lorsque cette commande se termine, celui-ci est arrêté. Pour plus d’informations, consultez Manifestes publicitaires.

Arguments

PROJECT | SOLUTION | FILE

Fichier projet ou solution ou C# (application basée sur des fichiers) sur lequel fonctionner. Si aucun fichier n’est spécifié, MSBuild recherche dans le répertoire actif un projet ou une solution.

• PROJECT est le chemin d’accès et le nom de fichier d’un fichier projet C#, F# ou Visual Basic, ou le chemin d’un répertoire qui contient un fichier projet C#, F# ou Visual Basic.

• SOLUTION est le chemin d’accès et le nom de fichier d’un fichier solution (.sln ou extension .slnx), ou le chemin d’accès à un répertoire qui contient un fichier solution.

• FILE est un argument ajouté dans .NET 10. Chemin d’accès et nom de fichier d’une application basée sur un fichier. Les applications basées sur des fichiers sont contenues dans un fichier unique généré et exécuté sans fichier de projet (.csproj) correspondant. Pour plus d’informations, consultez Générer des applications C# basées sur des fichiers.

Options

• -a|--arch <ARCHITECTURE>

  Spécifie l’architecture cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --arch x86 définit le RID sur win-x86. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6 Preview 7.

• --artifacts-path <ARTIFACTS_DIR>

  Tous les fichiers de sortie de build de la commande exécutée vont dans les sous-dossiers sous le chemin spécifié, séparés par projet. Pour plus d’informations, consultez Disposition de sortie d’artefacts. Disponible depuis le Kit de développement logiciel (SDK) .NET 8.

• -bl|--binaryLogger:<FILE>

  Active l’enregistreur d’événements binaires et spécifie éventuellement le nom du fichier de sortie.
  Si aucun nom de fichier n’est fourni, la valeur par défaut se trouve msbuild.binlog dans le répertoire actif.

  Le journal binaire contient des informations de build détaillées et peut être ouvert avec msBuild Structured Log Viewer.

  dotnet build -bl
  dotnet build -bl:build-log.binlog
  

• -c|--configuration <CONFIGURATION>

  Définit la configuration de build. Pour la plupart des projets, la valeur par défaut est Debug, mais vous pouvez modifier les paramètres de configuration de build de votre projet.

• --disable-build-servers

  Force la commande à ignorer tous les serveurs de build persistants. Cette option offre un moyen cohérent de désactiver toute utilisation de la mise en cache de build, ce qui force une build à partir de zéro. Une build qui ne repose pas sur des caches est utile quand les caches peuvent être endommagés ou incorrects pour une raison quelconque. Disponible depuis le SDK .NET 7.

• -f|--framework <FRAMEWORK>

  Compile pour un framework spécifique. Le framework doit être défini dans le fichier projet. Exemples : net7.0, net462.

• --force

  Force la résolution de toutes les dépendances même si la dernière restauration a réussi. Définir cet indicateur revient à supprimer le fichier project.assets.json.

• --interactive

  Permet à la commande de s’arrêter et d’attendre une action ou une entrée utilisateur. Par exemple, pour effectuer une authentification.

• --no-dependencies

  Ignore les références entre projets (P2P) et génère uniquement le projet racine spécifié.

• --no-incremental

  Marque la build comme unsafe pour la génération incrémentielle. Cet indicateur désactive la compilation incrémentielle et force une regénération du graphique de dépendance du projet.

• --no-restore

  N’exécute pas de restauration implicite pendant la génération.

• --nologo

  N’affiche pas la bannière de démarrage ni le message de copyright.

• --no-self-contained

  Publiez votre application en tant qu’application dépendante de l’infrastructure. Un runtime .NET compatible doit être installé sur l’ordinateur cible pour exécuter votre application.

• -o|--output <OUTPUT_DIRECTORY>

  Répertoire dans lequel placer les fichiers binaires générés. S’il n’est pas spécifié, le chemin d'accès par défaut est ./bin/<configuration>/<framework>/. Pour les projets comportant plusieurs frameworks cibles (via la propriété TargetFrameworks), vous devez également définir --framework lorsque vous spécifiez cette option.

  • Kit SDK .NET 7.0.200 et versions ultérieures

    Si vous spécifiez l’option --output lors de l’exécution de cette commande sur une solution, l’interface CLI émet un avertissement (une erreur dans la version 7.0.200) en raison du manque de clarté de la sémantique du chemin de sortie. L’option --output n’est pas autorisée, car toutes les sorties de tous les projets générés seraient copiées dans le répertoire spécifié. Or, cette configuration n’est compatible ni avec les projets à plusieurs cibles, ni avec les projets présentant différentes versions de dépendances directes et transitives. Pour plus d’informations, consultez Option --output au niveau de la solution non valide pour les commandes liées à la build.

• --os <OS>

  Spécifie le système d’exploitation cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --os linux définit le RID sur linux-x64. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6.

• -p|--property:<PROPERTYNAME>=<VALUE>

  Définit une ou plusieurs propriétés de MSBuild. Spécifiez plusieurs propriétés délimitées par des points-virgules ou en répétant l’option :

  --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
  --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
  

• -r|--runtime <RUNTIME_IDENTIFIER>

  Spécifie le runtime cible. Pour connaître les identificateurs de runtime, consultez le catalogue des identificateurs de runtime. Si vous utilisez cette option avec le SDK .NET 6, utilisez --self-contained ou --no-self-contained également. En l’absence de spécification, la valeur par défaut consiste à générer pour le système d’exploitation et l’architecture actuels.

• --sc|--self-contained

  Publiez le runtime .NET avec votre application afin que le runtime n’ait pas besoin d’être installé sur l’ordinateur cible.

• --source <SOURCE>

  URI de la source du package NuGet à utiliser pendant l’opération de restauration.

• --tl:[auto|on|off]

  Spécifie si Terminal Logger doit être utilisé pour la sortie de build. La valeur par défaut est auto, qui vérifie d’abord l’environnement avant d’activer la journalisation du terminal. La vérification de l’environnement vérifie que le terminal est capable d’utiliser des fonctionnalités de sortie modernes et n’utilise pas une sortie standard redirigée avant d’activer le nouvel enregistreur d’événements. on ignore la vérification de l’environnement et active la journalisation du terminal. off ignore la vérification de l’environnement et utilise l’enregistreur d’événements de console par défaut.

  Terminal Logger vous montre la phase de restauration suivie de la phase de génération. Au cours de chaque phase, les projets en cours de génération apparaissent en bas du terminal. Chaque projet en cours de génération génère à la fois la cible MSBuild en cours de génération et le temps consacré à cette cible. Vous pouvez rechercher ces informations pour en savoir plus sur la génération. Lorsque la génération d’un projet est terminée, une unique section « build terminée » est écrite et capture :

  • Le nom du projet généré.
  • Le framework cible (si plusieurs cibles).
  • L’état de cette build.
  • La sortie principale de cette génération (qui est un lien hypertexte).
  • Les diagnostics générés pour ce projet.

  Cette option est disponible à partir de .NET 8.

• --ucr|--use-current-runtime

  Utilisez le runtime actuel comme runtime cible.

• -v|--verbosity <LEVEL>

  Définit le niveau de détail de la commande. Les valeurs autorisées sont q[uiet], m[inimal], n[ormal], d[etailed] et diag[nostic]. Pour plus d’informations, consultez LoggerVerbosity.

• --version-suffix <VERSION_SUFFIX>

  Définit la valeur de la propriété $(VersionSuffix) à utiliser lors de la génération du projet. Cela fonctionne uniquement si la propriété $(Version) n’est pas définie. Ensuite, $(Version) est défini sur $(VersionPrefix) combiné avec $(VersionSuffix), séparés par un tiret.

• -?|-h|--help

  Imprime une description de l’utilisation de la commande.

Exemples

• Générer un projet et ses dépendances :

  dotnet build
  

• Créez une application basée sur des fichiers :

  dotnet build MyProject.cs
  

  La prise en charge des applications basée sur des fichiers a été ajoutée dans le Kit de développement logiciel (SDK) .NET 10.0.100.

• Générer un projet et ses dépendances à l’aide de la configuration Release :

  dotnet build --configuration Release
  

• Générez un projet et ses dépendances pour un runtime spécifique (dans cet exemple, Linux) :

  dotnet build --runtime linux-x64
  

• Générez le projet et utilisez la source de package NuGet spécifiée pendant l’opération de restauration :

  dotnet build --source c:\packages\mypackages
  

• Générez le projet et définissez la version 1.2.3.4 en tant que paramètre de build à l’aide de l’option -pMSBuild :

  dotnet build -p:Version=1.2.3.4