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

Article
11/01/2024

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

Chaque commutateur est disponible sous deux formes : -switch et /switch. La documentation présente seulement la forme -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, les listes d’arguments d’un commutateur (séparés par des points-virgules ou des virgules) pourraient nécessiter des guillemets simples ou doubles pour garantir que les listes sont transmises à 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. Par conséquent, cette référence s’applique lorsque vous utilisez ces commandes. Toutefois dotnet run , elle ne l’est 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 actif une extension de nom de fichier se terminant par proj et utilise ce fichier. Vous pouvez aussi spécifier un fichier 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 des parties facultatives [] et des accolades {}indiquent des valeurs fournies par l’utilisateur.

Switch	Description
`-detailedSummary[:{True or False}]` `-ds[:{True or False}]`	Si `True`, afficher des informations détaillées à la fin du journal de génération sur les configurations qui ont été générées et sur la façon dont elles ont été planifiées sur les 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}]`	Entraîne la construction et la génération d’un graphe de projet par MSBuild. La construction d’un graphe implique l’identification des références de projet aux dépendances du formulaire. La création de ce graphe implique la tentative de création de références de projet avant les projets qui les référencent, ce qui est différent de la planification MSBuild traditionnelle. Nécessite MSBuild 16 ou version ultérieure.
`-help` `/?` ou `-h`	Affichez des informations sur l’utilisation. La commande suivante est un exemple : `msbuild.exe -?`
`-ignoreProjectExtensions: {extensions}` `-ignore: {extensions}`	Ignore les extensions spécifiées au moment de déterminer quel fichier projet générer. Utilisez un point-virgule ou une virgule pour séparer les différentes extensions, comme dans l'exemple suivant : `-ignoreprojectextensions:.vcproj,.sln`
`-inputResultsCaches[:{cacheFile; ...}]` `-irc[:{cacheFile; ...}]`	Liste séparée par des points-virgules des fichiers du cache d’entrée à partir desquels MSBuild lit les résultats de la génération. Si `-isolateProjects` est défini sur `False`, cela le définit sur `True`.
`-interactive[:{True or False}]`	Indique que les actions du 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. Les options `-interactive` et `-interactive:true` sont équivalentes. Utilisez le paramètre pour remplacer une valeur qui provient d’un fichier réponse.
`-isolateProjects[:{True, MessageUponIsolationViolation, False}]` `-isolate[:{True, MessageUponIsolationViolation, False}]`	Entraîne la génération de chaque projet par MSBuild de manière isolée. Si la valeur 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}]`	MSBuild s’exécute avec une faible priorité. Les options `-lowPriority` et `-lowPriority:True` sont équivalentes.
`-maxCpuCount[:{number}]` `-m[:{number}]`	Spécifie le nombre maximal de processus simultanés à utiliser au moment 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 parallèle de plusieurs projets. Dans l'exemple suivant, MSBuild a pour instruction de générer en utilisant trois processus MSBuild, ce qui permet de générer simultanément trois projets : `msbuild myproject.proj -maxcpucount:3`
`-noAutoResponse` `-noautorsp`	N’inclut automatiquement aucun fichier MSBuild.rsp ou Directory.Build.rsp.
`-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 sont conservés à l'issue de la génération pour permettre aux générations suivantes de les utiliser (par défaut). - False. Les nœuds ne sont pas conservés à l'issue de la génération. Un nœud correspond à un projet en cours d’exécution. Si vous incluez le commutateur, plusieurs nœuds peuvent s’exécuter `-maxcpucount` simultanément.
`-nologo`	N'affiche pas la bannière de démarrage ni le message de copyright.
`-preprocess[:{filepath}]` `-pp[:{filepath}]`	Crée un fichier projet agrégé unique en incorporant tous les fichiers qui seraient importés lors d'une génération, avec une indication de leurs limites. Vous pouvez utiliser ce commutateur pour identifier plus facilement les fichiers importés, leur emplacement d'origine, ainsi que les fichiers qui contribuent à la génération. Quand ce commutateur est utilisé, 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 les articles Import, élément (MSBuild) et Guide pratique pour utiliser la même cible dans plusieurs fichiers projet.
`-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`, cela le définit sur `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 tabulations est généré.
`-property:{name}={value}` `-p:{name}={value}`	Définit ou substitue les propriétés de niveau projet spécifiées, `name` correspondant au nom de la propriété et `value` à 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 dans l'exemple suivant : `-property:WarningLevel=2;OutDir=bin\Debug` Consultez les propriétés courantes du projet MSBuild 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` par 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ère 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 dans 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 dans le `DefaultTargets` fichier projet. Pour plus d’informations, consultez Ordre de génération des cibles 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 l’article Targets (Cibles MSBuild).
`-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 des tâches, des cibles et des outils utilisés pour générer une application. Consultez Ensemble d’outils (ToolsVersion) et Configurations standard et personnalisées des ensembles d’outils.
`-validate:[{schema}]` `-val[{schema}]`	Valide le fichier projet et, si la validation réussit, génère 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. Voici un exemple de paramétrage : `-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 commentaires que vous définissez pour l'enregistreur d'événements en question. Vous pouvez spécifier les niveaux de commentaires suivantes : `q[uiet]`, `m[inimal]`, `n[ormal]` (par défaut), `d[etailed]` et `diag[nostic]`. Voici un exemple de paramétrage : `-verbosity:quiet`
`-version` `-ver`	Affiche uniquement les informations de version. Le projet n’est pas généré.
`@{file}`	Insère des commutateurs de ligne de commande à partir d'un fichier texte. Si vous avez plusieurs fichiers, spécifiez-les séparément. Pour plus d’informations, consultez Fichiers réponse.
`-warnAsError[:{code; ...}]` `-err[:{code; ...}]`	Liste de 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 valeur. 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 de codes d’avertissement à traiter comme des messages de faible importance. Utilisez un point-virgule ou une virgule pour séparer plusieurs codes d’avertissement. Exemple : `-noWarn:MSB3026`

Commutateurs pour les enregistreurs d’événements

Switch	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 est 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é plus tard pour reconstruire les journaux de texte et pour servir à d’autres outils d’analyse. Un journal binaire est généralement 10 à 20 fois plus petit que le plus détaillé des journaux de texte du niveau diagnostic, mais il contient davantage d’informations. Par défaut, l’enregistreur d’événements binaire collecte le texte source des fichiers projet, y compris tous les projets importés et les fichiers cibles rencontrés pendant la build. Le paramètre facultatif `ProjectImports` contrôle ce comportement : - ProjectImports = None. Ne pas collecter les importations du projet. - ProjectImports=Embed. Incorporer les importations du projet dans le fichier journal (par défaut). - ProjectImports = ZipFile. Enregistrez les fichiers projet dans {output}.projectimports.zip où <la sortie> est le même nom que le nom du fichier journal binaire. Le paramètre par défaut pour ProjectImports est Embed. Remarque : l’enregistreur d’événements ne collecte pas les fichiers sources non MSBuild tels que `.cs`, `.cpp`et ainsi de suite. Un fichier .binlog peut être « lu » en le passant à msbuild.exe en tant qu’argument à la place d’un projet ou d’une solution. D’autres enregistreurs d’événements reçoivent les informations contenues dans le fichier journal comme si la build d’origine se produisait. Pour plus d’informations sur le journal binaire et ses usages, consultez : 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}`	Passe 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 ajouter les paramètres suivants : - PerformanceSummary. Affiche le temps consacré aux tâches, cibles et projets. - Summary. affiche le résumé des erreurs et avertissements à la fin. - NoSummary. n'affiche pas le résumé des erreurs et avertissements à la fin. - ErrorsOnly. affiche uniquement les erreurs. - WarningsOnly. affiche uniquement les avertissements. - NoItemAndPropertyList. n'affiche pas la liste des éléments et des propriétés qui apparaîtrait au début de chaque génération de projet si le niveau de commentaires défini était `diagnostic`. - ShowCommandLine. affiche les messages `TaskCommandLineEvent`. - ShowProjectFile. Affichez le chemin du fichier projet dans les messages de diagnostic. Ce paramètre est activé par défaut. - ShowTimestamp. affiche l'horodatage sous forme de préfixe des messages. - ShowEventId. affiche l'ID d'événement pour chaque message et événement (démarré et terminé). - ForceNoAlign. n'adapte pas le texte à la taille de la mémoire tampon de la console. - DisableConsoleColor. utilise les couleurs de console par défaut pour tous les messages de journalisation. - DisableMPLogging. désactive le style de journalisation multiprocesseur de la sortie lors d'une exécution en mode non multiprocesseur. - EnableMPLogging. active le style de journalisation multiprocesseur même lors d'une exécution 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 de cet enregistreur d’événements `-verbosity` . Utilisez un point-virgule pour séparer plusieurs paramètres, comme dans l'exemple suivant : `-consoleloggerparameters:PerformanceSummary;NoSummary -verbosity:minimal` L’enregistreur d’événements de console par défaut a un niveau de détail normal et inclut un `Summary`.
`-distributedFileLogger` `-dfl`	consigne la sortie de génération 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 `-fileLoggerParameters` commutateur pour spécifier l’emplacement des fichiers et d’autres paramètres pour fileLogger. Si vous nommez un fichier journal à l’aide du `-fileLoggerParameters` commutateur, 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, ...}`	Consigne les événements de MSBuild, en joignant une instance d'enregistreur d'événements différente à chaque nœud. Pour spécifier plusieurs enregistreurs d'événements, spécifiez-les 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 `-logger` commutateur. 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}]`	Consigne la sortie de génération 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 compris entre 1 et 9. Vous pouvez utiliser le `-fileLoggerParameters` commutateur pour spécifier l’emplacement du fichier et d’autres paramètres pour fileLogger.
`-fileLoggerParameters[{number}]:` `parameters` `-flp[{number}]: {parameters}`	Spécifie les paramètres supplémentaires de l'enregistreur d'événements des fichiers et de l'enregistreur d'événements des fichiers distribué. La présence de ce commutateur implique que le commutateur correspondant `-filelogger[number]` soit présent. `Number` peut être un chiffre compris entre 1 et 9. Vous pouvez utiliser tous les paramètres répertoriés pour `-consoleloggerparameters`. Vous pouvez aussi utiliser un ou plusieurs des paramètres suivants : - LogFile. chemin d’accès au fichier journal dans lequel le journal de génération est écrit. L’enregistreur d’événements des fichiers distribué accole en préfixe ce chemin d’accès au nom de ses fichiers journaux. - Append. détermine si le journal de génération est ajouté au fichier journal ou s'il le remplace. Quand 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 `true` ou `false` explicite, le journal est ajouté quel que soit le 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` - Encoding. spécifie l'encodage pour le 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 consigner les événements de MSBuild. Pour spécifier plusieurs enregistreurs d'événements, spécifiez-les séparément. Utilisez la syntaxe suivante pour `logger` : `[LoggerClass,]LoggerAssembly[;LoggerParameters]` Utilisez la syntaxe suivante pour `LoggerClass` : `[PartialOrFullNamespace.]LoggerClassName` Vous n'êtes pas obligé 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 au moment même où vous les entrez. Les exemples suivants utilisent le `-logger` commutateur. `-logger:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral` `-logger:XMLLogger,C:\Loggers\MyLogger.dll;OutputAsHTML`
`-noConsoleLogger` `-noconlog`	Désactive l'enregistreur d'événements de console par défaut et ne consigne pas les événements dans 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 arguments) 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 1

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

MSBuild.exe MyProject.proj -t:rebuild

Exemple 2

Vous pouvez utiliser MSBuild.exe pour effectuer des générations plus complexes. Par exemple, vous pouvez l'utiliser pour générer des cibles spécifiques de certains projets dans le cadre d'une solution. L’exemple suivant regénère le projet NotInSolutionFolder et nettoie le projet InSolutionFolder qui se trouve dans le dossier de solution NewFolder.

msbuild SlnFolders.sln -t:NotInSolutionfolder:Rebuild;NewFolder\InSolutionFolder:Clean

Partager via