Partage via

Informations de référence sur la ligne de commande MSBuild

  • Article

Lorsque vous utilisez MSBuild.exe pour générer un fichier projet ou solution, vous pouvez inclure plusieurs commutateurs pour spécifier différents aspects du processus.

Chaque commutateur est disponible sous deux formes : -switch et /switch. La documentation affiche uniquement le formulaire -switch. Les commutateurs ne respectent pas la casse. Si vous exécutez MSBuild à partir d’un interpréteur de commandes autre que l’invite de commandes Windows, des listes d’arguments à un commutateur (séparés par des points-virgules ou des virgules) peuvent avoir besoin de guillemets simples ou doubles pour vous assurer que les listes sont passées à MSBuild au lieu d’être interprétées par l’interpréteur de commandes.

Les commandes CLI .NET dotnet build, dotnet publish, dotnet msbuild et les commandes associées passent ces commutateurs à MSBuild. Cette référence s’applique donc lorsque vous utilisez ces commandes ; cependant dotnet run ne le fait pas.

Syntaxe

MSBuild.exe [Switches] [ProjectFile]

Arguments

Argument Description
ProjectFile Génère les cibles dans le fichier projet que vous spécifiez. Si vous ne spécifiez pas de fichier projet, MSBuild recherche dans le répertoire de travail actuel une extension de nom de fichier qui se termine par proj et utilise ce fichier. Vous pouvez également spécifier un fichier de solution Visual Studio pour cet argument.

Commutateurs

La première colonne du tableau suivant présente une forme longue et courte de chaque commutateur. Les deux formulaires sont équivalents.

Les crochets [] indiquent les parties facultatives et les accolades {}indiquer les valeurs fournies par l’utilisateur.

Interrupteur Description
-detailedSummary[:{True or False}]

-ds[:{True or False}]		 Si True, affichez des informations détaillées à la fin du journal de build sur les configurations qui ont été générées et la façon dont elles ont été planifiées sur des nœuds.
-getItem:{itemName,...} Écrivez la valeur de l’élément ou des éléments après l’évaluation, sans exécuter la build, ou si l’option -targets ou l’option -getTargetResult est utilisée, écrivez les valeurs après la génération.
-getProperty:{propertyName,...} Écrivez la valeur de la propriété ou des propriétés après l’évaluation, sans exécuter la build, ou si l’option -targets ou l’option -getTargetResult est utilisée, écrivez les valeurs après la génération.
-getTargetResult:{targetName,...} Écrivez les valeurs de sortie des cibles spécifiées.
-graphBuild[:{True or False}]

-graph[:{True or False}]		 Provoque la construction et la génération d’un graphe de projet par MSBuild. La construction d’un graphique implique l’identification des références de projet pour former des dépendances. La création de ce graphique implique la tentative de génération de références de projet avant les projets qui les référencent, ce qui diffère de la planification MSBuild traditionnelle. Nécessite MSBuild 16 ou version ultérieure.
-help

/? ou -h		 Affichez les informations d’utilisation. La commande suivante est un exemple :

msbuild.exe -?
-ignoreProjectExtensions: {extensions}

-ignore: {extensions}		 Ignorez les extensions spécifiées lors de la détermination du fichier projet à générer. Utilisez un point-virgule ou une virgule pour séparer plusieurs extensions, comme l’illustre l’exemple suivant :

-ignoreprojectextensions:.vcproj,.sln
-inputResultsCaches[:{cacheFile; ...}]

-irc[:{cacheFile; ...}]		 Liste séparée par des points-virgules des fichiers de cache d’entrée à partir duquel MSBuild lit les résultats de build. Si -isolateProjects est défini sur False, cette valeur est True.
-interactive[:{True or False}] Indique que les actions dans la build sont autorisées à interagir avec l’utilisateur. N’utilisez pas cet argument dans un scénario automatisé où l’interactivité n’est pas attendue. La spécification de -interactive est la même que la spécification de -interactive:true. Utilisez le paramètre pour remplacer une valeur provenant d’un fichier réponse.
-isolateProjects[:{True, MessageUponIsolationViolation, False}]

-isolate[:{True, MessageUponIsolationViolation, False}]		 Entraîne la génération de chaque projet par MSBuild en isolation. Lorsqu’elle est définie sur MessageUponIsolationViolation (ou sa forme abrégée Message), seuls les résultats des cibles de niveau supérieur sont sérialisés si le commutateur -outputResultsCache est fourni. Cette option consiste à atténuer les chances d’une cible en violation d’isolement sur un projet de dépendance à l’aide d’un état incorrect en raison de sa dépendance vis-à-vis d’une cible mise en cache dont les effets secondaires ne seraient pas pris en compte. (Par exemple, la définition d’une propriété.) Ce mode est plus restrictif, car il nécessite que le graphique de projet soit détectable de manière statique au moment de l’évaluation, mais peut améliorer la planification et réduire la surcharge de mémoire lors de la création d’un grand ensemble de projets.
-lowPriority[:{True or False}]

-low[:{True or False}]		 Entraîne l’exécution de MSBuild à une priorité de processus faible. La spécification de -lowPriority est la même que la spécification de -lowPriority:True.
-maxCpuCount[:{number}]

-m[:{number}]		 Spécifie le nombre maximal de processus simultanés à utiliser lors de la génération. Si vous n’incluez pas ce commutateur, la valeur par défaut est 1. Si vous incluez ce commutateur sans spécifier de valeur, MSBuild utilise jusqu’au nombre de processeurs de l’ordinateur. Pour plus d’informations, consultez Génération de plusieurs projets en parallèle.

L’exemple suivant indique à MSBuild de générer à l’aide de trois processus MSBuild, ce qui permet à trois projets de générer en même temps :

msbuild myproject.proj -maxcpucount:3
-noAutoResponse

-noautorsp		 N’incluez aucun fichier MSBuild.rsp ou Directory.Build.rsp automatiquement.
-nodeReuse:{value}

-nr:{value}		 Activez ou désactivez la réutilisation des nœuds MSBuild. Vous pouvez spécifier les valeurs suivantes :

- True. Les nœuds restent une fois la build terminée afin que les builds suivantes puissent les utiliser (par défaut).
- False. Les nœuds ne restent pas une fois la build terminée.

Un nœud correspond à un projet en cours d’exécution. Si vous incluez le commutateur -maxcpucount, plusieurs nœuds peuvent s’exécuter simultanément.
-nologo N’affichez pas la bannière de démarrage ou le message de copyright.
-preprocess[:{filepath}]

-pp[:{filepath}]		 Créez un fichier projet agrégé unique en inlinant tous les fichiers importés pendant une build, avec leurs limites marquées. Vous pouvez utiliser ce commutateur pour déterminer plus facilement les fichiers importés, à partir de l’emplacement où les fichiers sont importés et les fichiers qui contribuent à la build. Lorsque vous utilisez ce commutateur, le projet n’est pas généré.

Si vous spécifiez un filepath, le fichier projet agrégé est généré dans le fichier. Sinon, la sortie s’affiche dans la fenêtre de console.

Pour plus d’informations sur l’utilisation de l’élément Import pour insérer un fichier projet dans un autre fichier projet, consultez élément Import (MSBuild) et How to : Use the same target in multiple project files.
-outputResultsCache[:{cacheFile}]

-orc[:{cacheFile}]		 Fichier de cache de sortie où MSBuild écrit le contenu de ses caches de résultats de build à la fin de la build. Si -isolateProjects est défini sur False, cette valeur est True.
profileEvaluation:{file} Profile l’évaluation MSBuild et écrit le résultat dans le fichier spécifié. Si l’extension du fichier spécifié est « .md », le résultat est généré au format Markdown. Sinon, un fichier séparé par des onglets est généré.
-property:{name}={value}

-p:{name}={value}		 Définissez ou remplacez les propriétés spécifiées au niveau du projet, où name est le nom de la propriété et value est la valeur de la propriété. Spécifiez chaque propriété séparément, ou utilisez un point-virgule ou une virgule pour séparer plusieurs propriétés, comme l’illustre l’exemple suivant :

-property:WarningLevel=2;OutDir=bin\Debug

Consultez propriétés de projet MSBuild courantes pour obtenir la liste des propriétés couramment utilisées. L’ensemble complet de propriétés disponibles dépend du type de projet, du SDK et des fichiers importés.
-restore

-r		 Exécute la cible Restore avant de générer les cibles réelles.
-restoreProperty:{name}={value}

-rp:{name}={value}		 Définissez ou remplacez ces propriétés au niveau du projet uniquement pendant la restauration et n’utilisez pas les propriétés spécifiées avec l’argument -property. name est le nom de la propriété et value est la valeur de la propriété. Utilisez un point-virgule ou une virgule pour séparer plusieurs propriétés, ou spécifiez chaque propriété séparément.
-target:{targets}

-t:{targets}		 Générez les cibles spécifiées dans le projet. Spécifiez chaque cible séparément, ou utilisez un point-virgule ou une virgule pour séparer plusieurs cibles, comme l’illustre l’exemple suivant :

-target:PrepareResources;Compile

Si vous spécifiez des cibles à l’aide de ce commutateur, elles sont exécutées au lieu d’une cible dans l’attribut DefaultTargets dans le fichier projet. Pour plus d’informations, consultez 'ordre de génération cible et Guide pratique pour spécifier la cible à générer en premier.

Une cible est un groupe de tâches. Pour plus d’informations, consultez Cibles.
-targets[:{file}]

-ts[:{file}]		 Écrivez la liste des cibles disponibles dans le fichier spécifié (ou l’appareil de sortie, si aucun fichier n’est spécifié), sans exécuter réellement le processus de génération.
-toolsVersion:{version}

-tv:{version}		 Spécifie un ensemble d’outils personnalisé. Un ensemble d’outils se compose de tâches, de cibles et d’outils utilisés pour générer une application. Consultez ensemble d’outils (ToolsVersion) et configurations d’ensemble d’outils standard et personnalisées.
-validate:[{schema}]

-val[{schema}]		 Validez le fichier projet et, si la validation réussit, générez le projet.

Si vous ne spécifiez pas schema, le projet est validé par rapport au schéma par défaut.

Si vous spécifiez schema, le projet est validé par rapport au schéma que vous spécifiez.

Le paramètre suivant est un exemple : -validate:MyExtendedBuildSchema.xsd
-verbosity:{level}

-v:{level}		 Spécifie la quantité d’informations à afficher dans le journal de génération. Chaque enregistreur d’événements affiche les événements en fonction du niveau de détail que vous avez défini pour cet enregistreur d’événements.

Vous pouvez spécifier les niveaux de détail suivants : q[uiet], m[inimal], n[ormal] (valeur par défaut), d[etailed]et diag[nostic].

Le paramètre suivant est un exemple : -verbosity:quiet
-version

-ver		 Afficher uniquement les informations de version. Le projet n’est pas généré.
@{file} Insérer des commutateurs de ligne de commande à partir d’un fichier texte. Si vous avez plusieurs fichiers, vous les spécifiez séparément. Pour plus d’informations, consultez fichiers Response.
-warnAsError[:{code; ...}]

-err[:{code; ...}]		 Liste des codes d’avertissement à traiter comme des erreurs. Utilisez un point-virgule ou une virgule pour séparer plusieurs codes d’avertissement. Pour traiter tous les avertissements comme des erreurs, utilisez le commutateur sans valeurs. Lorsqu’un avertissement est traité comme une erreur, la cible continue à s’exécuter comme s’il s’agissait d’un avertissement, mais la build globale échoue.

Exemple : -err:MSB4130
-warnNotAsError[:{code; ...}]

-noerr[:{code; ...}]		 MSBuild 17.0 et versions ultérieures. Liste des codes d’avertissement qui ne doivent pas être promus en erreurs. Plus précisément, si le commutateur warnAsError est défini pour promouvoir tous les avertissements en erreurs, les codes d’erreur spécifiés avec warnNotAsError ne sont pas promus. Cela n’a aucun effet si warnAsError n’est pas défini pour promouvoir tous les avertissements en erreurs. Utilisez un point-virgule ou une virgule pour séparer plusieurs codes d’avertissement.

Exemple : -noerr:MSB4130
-warnAsMessage[:{code}; ...}]

-noWarn[:{code; ...}]		 Liste des codes d’avertissement à traiter comme des messages d’importance faible. Utilisez un point-virgule ou une virgule pour séparer plusieurs codes d’avertissement.

Exemple : -noWarn:MSB3026

Commutateurs pour les enregistreurs d’événements

Interrupteur Description
-binaryLogger[:[LogFile=]{output.binlog}
[;ProjectImports=None,Embed,ZipFile]]

-bl[:[LogFile=]{output.binlog}
[;ProjectImports=None,Embed,ZipFile]]		 Sérialise tous les événements de build dans un fichier binaire compressé. Par défaut, le fichier se trouve dans le répertoire actif et nommé msbuild.binlog. Le journal binaire est une description détaillée du processus de génération qui peut être utilisé ultérieurement pour reconstruire des journaux de texte et utilisé par d’autres outils d’analyse. Un journal binaire est généralement de 10 à 20x plus petit que le journal de diagnostic de texte le plus détaillé, mais il contient plus d’informations.

L’enregistreur d’événements binaire par défaut collecte le texte source des fichiers projet, y compris tous les projets importés et les fichiers cibles rencontrés pendant la génération. Le paramètre ProjectImports facultatif contrôle ce comportement :

- ProjectImports=Aucun. Ne collectez pas les importations du projet.
- ProjectImports=Embed. Incorporer les importations de projet dans le fichier journal (valeur par défaut).
- ProjectImports=ZipFile. Enregistrez les fichiers projet dans {output}.projectimports.zip où <sortie> est le même nom que le nom du fichier journal binaire.

Le paramètre par défaut de ProjectImports est Embed.
Remarque: l’enregistreur d’événements ne collecte pas les fichiers sources non MSBuild tels que .cs, .cpp, etc.
Un fichier .binlog peut être « lu » en le transmettant à msbuild.exe en tant qu’argument au lieu d’un projet/solution. D’autres enregistreurs d’événements reçoivent les informations contenues dans le fichier journal comme si la build d’origine se produisait. Vous pouvez en savoir plus sur le journal binaire et ses utilisations sur : https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md

exemples :
- -bl
- -bl:output.binlog
- -bl:output.binlog;ProjectImports=None
- -bl:output.binlog;ProjectImports=ZipFile
- -bl:..\..\custom.binlog
- -binaryLogger
-consoleLoggerParameters:{parameters}

-clp:{parameters}		 Transmettez les paramètres que vous spécifiez à l’enregistreur d’événements de console, qui affiche les informations de build dans la fenêtre de console. Vous pouvez spécifier les paramètres suivants :

- PerformanceSummary. Affichez le temps passé dans les tâches, les cibles et les projets.
- Résumé. Affichez le résumé de l’erreur et de l’avertissement à la fin.
- NoSummary. N’affichez pas le résumé de l’erreur et de l’avertissement à la fin.
- ErrorsOnly. Afficher uniquement les erreurs.
- WarningsOnly. Afficher uniquement les avertissements.
- NoItemAndPropertyList. N’affichez pas la liste des éléments et des propriétés qui s’affichent au début de chaque build de projet si le niveau de détail est défini sur diagnostic.
- ShowCommandLine. Afficher les messages TaskCommandLineEvent.
- ShowProjectFile. Affichez le chemin d’accès au fichier projet dans les messages de diagnostic. Ce paramètre est activé par défaut.
- showTimestamp. Affichez l’horodatage comme préfixe pour n’importe quel message.
- ShowEventId. Affichez l’ID d’événement pour chaque événement démarré, événement terminé et message.
- ForceNoAlign. N’alignez pas le texte sur la taille de la mémoire tampon de la console.
- DisableConsoleColor. Utilisez les couleurs de console par défaut pour tous les messages de journalisation.
- DisableMPLogging. Désactivez le style de journalisation multiprocesseur de sortie lors de l’exécution en mode non multiprocesseur.
- enableMPLogging. Activez le style de journalisation multiprocesseur même en mode non multiprocesseur. Ce style de journalisation est activé par défaut.
- ForceConsoleColor. Utilisez les couleurs de la console ANSI même si la console ne la prend pas en charge.
- verbosity . Remplacez le paramètre -verbosity pour cet enregistreur d’événements.

Utilisez un point-virgule pour séparer plusieurs paramètres, comme l’illustre l’exemple suivant :

-consoleLoggerParameters:PerformanceSummary;NoSummary -verbosity:minimal

L’enregistreur d’événements de console par défaut est détaillé normal et inclut une Summary.
-distributedFileLogger

-dfl		 Consignez la sortie de build de chaque nœud MSBuild dans son propre fichier. L’emplacement initial de ces fichiers est le répertoire actif. Par défaut, les fichiers sont nommés MSBuild{NodeId}.log. Vous pouvez utiliser le commutateur -fileLoggerParameters pour spécifier l’emplacement des fichiers et d’autres paramètres pour fileLogger.

Si vous nommez un fichier journal à l’aide du commutateur -fileLoggerParameters, l’enregistreur d’événements distribué utilise ce nom comme modèle et ajoute l’ID de nœud à ce nom lors de la création d’un fichier journal pour chaque nœud.
-distributedLogger:{central logger},{forwarding logger}, ...

-dl:{central logger},{forwarding logger, ...}		 Journaliser les événements à partir de MSBuild, en attachant une instance d’enregistreur d’événements différente à chaque nœud. Pour spécifier plusieurs enregistreurs d’événements, spécifiez chaque enregistreur d’événements séparément.

Vous utilisez la syntaxe de l’enregistreur d’événements pour spécifier un enregistreur d’événements, sauf que vous fournissez et une classe supplémentaire pour l’enregistreur d’événements de transfert. Pour connaître la syntaxe de l’enregistreur d’événements, consultez le commutateur -logger.

Les exemples suivants montrent comment utiliser ce commutateur :

-dl:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral

-dl:MyLogger,C:\My.dll*ForwardingLogger,C:\Logger.dll
-fileLogger[{number}]

-fl[{number}]		 Consignez la sortie de build dans un fichier unique dans le répertoire actif. Si vous ne spécifiez pas number, le fichier de sortie est nommé msbuild.log. Si vous spécifiez number, le fichier de sortie est nommé msbuild<n>.log, où <n> est number. Number peut être un chiffre de 1 à 9.

Vous pouvez utiliser le commutateur -fileLoggerParameters pour spécifier l’emplacement du fichier et d’autres paramètres pour fileLogger.
-fileLoggerParameters[{number}]:

parameters

-flp[{number}]: {parameters}		 Spécifie tous les paramètres supplémentaires pour l’enregistreur d’événements de fichiers et l’enregistreur d’événements de fichiers distribués. La présence de ce commutateur implique que le commutateur de -filelogger[number] correspondant est présent. Number peut être un chiffre de 1 à 9.

Vous pouvez utiliser tous les paramètres répertoriés pour -consoleloggerparameters. Vous pouvez également utiliser un ou plusieurs des paramètres suivants :

- LogFile . Chemin d’accès au fichier journal dans lequel le journal de build est écrit. L’enregistreur d’événements de fichiers distribués préfixe ce chemin d’accès aux noms de ses fichiers journaux.
- Ajouter. Détermine si le journal de build est ajouté au fichier journal ou le remplace. Lorsque vous définissez le commutateur, le journal de génération est ajouté au fichier journal. Lorsque le commutateur n’est pas présent, le contenu d’un fichier journal existant est remplacé.
Exemple : msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log;append
Si vous incluez un paramètre explicite true ou false, le journal est ajouté indépendamment du paramètre. Si vous n’incluez pas le commutateur d’ajout, le journal est remplacé.
Dans ce cas, le fichier est remplacé : msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log
Dans ce cas, le fichier est ajouté : msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log;append=true
Dans ce cas, le fichier est ajouté : msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log;append=false
- d’encodage . Spécifie l’encodage du fichier (par exemple, UTF-8, Unicode ou ASCII).

L’exemple suivant génère des fichiers journaux distincts pour les avertissements et les erreurs :

-flp1:logfile=errors.txt;errorsonly -flp2:logfile=warnings.txt;warningsonly

Les exemples suivants montrent d’autres possibilités :

-fileLoggerParameters:LogFile=MyLog.log;Append; Verbosity=diagnostic;Encoding=UTF-8

-flp:Summary;Verbosity=minimal;LogFile=msbuild.sum

-flp1:warningsonly;logfile=msbuild.wrn

-flp2:errorsonly;logfile=msbuild.err
-logger:logger

-l:logger		 Spécifie l’enregistreur d’événements à utiliser pour journaliser les événements à partir de MSBuild. Pour spécifier plusieurs enregistreurs d’événements, spécifiez chaque enregistreur d’événements séparément.

Utilisez la syntaxe suivante pour logger: [LoggerClass,]LoggerAssembly[;LoggerParameters]

Utilisez la syntaxe suivante pour LoggerClass: [PartialOrFullNamespace.]LoggerClassName

Vous n’avez pas besoin de spécifier la classe d’enregistreur d’événements si l’assembly contient exactement un enregistreur d’événements.

Utilisez la syntaxe suivante pour LoggerAssembly: AssemblyName[,StrongName] \| AssemblyFile

Les paramètres d’enregistreur d’événements sont facultatifs et sont passés à l’enregistreur d’événements exactement à mesure que vous les entrez.

Les exemples suivants utilisent le commutateur -logger.

-logger:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral

-logger:XMLLogger,C:\Loggers\MyLogger.dll;OutputAsHTML
-noConsoleLogger

-noconlog		 Désactivez l’enregistreur d’événements de console par défaut et ne connectez pas les événements à la console.
-terminalLogger[:auto,on,off]

-tl[:auto,on,off]		 Activez ou désactivez l’enregistreur d’événements de terminal . L’enregistreur d’événements terminal fournit une sortie de build améliorée sur la console en temps réel, organisée logiquement par projet et conçue pour mettre en évidence les informations exploitables. Spécifiez auto (ou utilisez l’option sans argument) pour utiliser l’enregistreur d’événements terminal uniquement si la sortie standard n’est pas redirigée. N’analysez pas la sortie ou ne vous appuyez pas sur celle-ci restant inchangée dans les versions ultérieures. Cette option est disponible dans MSBuild 17.8 et versions ultérieures.

Exemple

L’exemple suivant génère la cible rebuild du projet MyProject.proj.

MSBuild.exe MyProject.proj -t:rebuild

Voir aussi