dotnet build

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

Nom

dotnet build : Génère un projet et l’ensemble de ses dépendances.

Synopsis

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

dotnet build -h|--help

Description

La commande dotnet build génère le projet 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, si le type de projet est un exécutable ciblant .NET Core 3.0 ou version ultérieure.
• 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 des versions antérieures à .NET Core 3.0, les dépendances de bibliothèque de NuGet ne sont généralement pas copiées dans le dossier de sortie. Elles sont résolues à partir du dossier de packages globaux NuGet au moment de l’exécution. Par conséquent, le produit de dotnet build ne peut pas être transféré en l’état vers un autre ordinateur pour exécution. Pour créer une version de l’application qui peut être déployée, vous devez la publier (par exemple, avec la commande dotnet publish). Pour plus d’informations, consultez Déploiement d’applications .NET.

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

La commande dotnet build utilise MSBuild pour générer le projet. Elle prend donc en charge les builds parallèles et les builds 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.

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

Le fichier projet ou solution à générer. Si vous ne spécifiez pas de fichier projet ou solution, MSBuild recherche dans le répertoire de travail actif un fichier dont l’extension se termine par proj ou sln et l’utilise.

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.

• -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.

• -?|-h|--help

  Imprime une description de l’utilisation de la commande.

• --interactive

  Permet à la commande de s’arrêter et d’attendre une action ou une entrée utilisateur. Par exemple, pour effectuer une authentification. Option disponible à partir du kit SDK .NET Core 3.0.

• --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

  Publie l’application en tant qu’application dépendante du framework. Un runtime .NET compatible doit être installé sur l’ordinateur cible pour exécuter l’application. Disponible à partir du kit SDK .NET 6.

• -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.

• --self-contained [true|false]

  Publie le runtime .NET avec l’application ; ainsi, vous n’avez pas besoin d’installer le runtime sur l’ordinateur cible. La valeur par défaut est true si un identificateur de runtime est spécifié. Disponible à partir de .NET 6.

• --source <SOURCE>

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

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

  Spécifie si l’enregistreur d’événements de terminal 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.

  L’enregistreur d’événements de terminal affiche la phase de restauration suivie par 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.

• -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]. Par défaut, il s’agit de minimal. Par défaut, MSBuild affiche des avertissements et des erreurs à tous les niveaux de détail. Pour exclure des avertissements, utilisez /property:WarningLevel=0. Pour plus d’informations, consultez LoggerVerbosity et WarningLevel.

• --use-current-runtime, --ucr [true|false]

  Définit l’élément RuntimeIdentifier sur une plateforme portable RuntimeIdentifier sur la base de l’un de vos ordinateurs. Cela se produit implicitement avec les propriétés qui nécessitent un RuntimeIdentifier, comme SelfContained, PublishAot, PublishSelfContained, PublishSingleFile et PublishReadyToRun. Si la propriété a la valeur false, cette résolution implicite ne se produit plus.

• --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.

Exemples

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

  dotnet build
  

• 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 -p MSBuild :

  dotnet build -p:Version=1.2.3.4