MSBuild-Befehlszeilenreferenz

Wenn Sie mithilfe von MSBuild.exe ein Projekt oder eine Projektmappendatei erstellen, können Sie diverse Optionen verwenden, um verschiedene Aspekte des Prozesses festzulegen.

Jeder Schalter ist in zwei Formen verfügbar: -switch und /switch. In der Dokumentation wird nur die Form „-switch“ gezeigt. Die Groß-/Kleinschreibung wird bei Schaltern nicht beachtet. Wenn Sie MSBuild über eine andere Shell als der Windows-Eingabeaufforderung ausführen, müssen Listen von Argumenten für eine switch-Anweisung (durch Semikolons oder Kommas getrennt) möglicherweise mit einfachen oder doppelten Anführungszeichen geschrieben werden, um dafür zu sorgen, dass die Listen an MSBuild übergeben werden, anstatt von der Shell interpretiert zu werden.

Die .NET CLI-Befehle dotnet build, dotnet publish, dotnet msbuild und related commands übergeben diese Switches an MSBuild, sodass diese Referenz gilt, wenn Sie diese Befehle verwenden. Dies ist jedoch dotnet run nicht der Fall.

Syntax

MSBuild.exe [Switches] [ProjectFile]

Argumente

Argument	Beschreibung
ProjectFile	Erstellt die Ziele in der von Ihnen angegebenen Projektdatei. Wenn Sie keine Projektdatei angeben, durchsucht MSBuild das aktuelle Arbeitsverzeichnis nach einer Erweiterung, die mit proj endet, und verwendet diese. Sie können hier auch eine Visual Studio-Projektmappendatei als Argument angeben.

Schalter

Die erste Spalte in der folgenden Tabelle zeigt eine lange und kurze Form der einzelnen Schalter. Beide Formulare sind gleichwertig.

Eckige Klammern geben optionale Teile an, und geschweifte Klammern [] {}geben vom Benutzer angegebene Werte an.

Schalter	Beschreibung
-detailedSummary[:{True or False}] -ds[:{True or False}]	Falls True, werden am Ende des Buildprotokolls ausführliche Informationen zu den erstellten Konfigurationen und deren Planung in Knoten angezeigt.
-getItem:{itemName,...}	Schreibt die Elemente nach der Auswertung, ohne den Build auszuführen, oder schreibt die Werte nach dem Build, wenn entweder die Option -targets oder die Option -getTargetResult verwendet wird.
-getProperty:{propertyName,...}	Schreibt den Wert der Eigenschaften nach der Auswertung, ohne den Build auszuführen, oder schreibt die Werte nach dem Build, wenn entweder die Option -targets oder die Option -getTargetResult verwendet wird.
-getTargetResult:{targetName,...}	Schreibt die Ausgabewerte der angegebenen Ziele.
-graphBuild[:{True or False}] -graph[:{True or False}]	Führt dazu, dass MSBuild einen Projektgraph konstruiert und erstellt. Das Konstruieren eines Graphs beinhaltet das Identifizieren der Projektverweise, um Abhängigkeiten zu erstellen. Das Erstellen dieses Graphs beinhaltet den Versuch, Projektverweise vor den Projekten zu erstellen, die die Verweise enthalten. Dieses Vorgehen unterscheidet sich vom herkömmlichen MSBuild-Vorgehen. Erfordert MSBuild 16 oder höher.
-help /? oder -h	Zeigt Nutzungsinformationen an. Der folgende Befehl ist ein Beispiel: msbuild.exe -?
-ignoreProjectExtensions: {extensions} -ignore: {extensions}	Ignoriert beim Bestimmen der zu erstellenden Projektdatei die angegebenen Erweiterungen. Mehrere Erweiterungen werden mit einem Semikolon oder einem Komma getrennt, wie im folgenden Beispiel gezeigt: -ignoreprojectextensions:.vcproj,.sln
-inputResultsCaches[:{cacheFile; ...}] -irc[:{cacheFile; ...}]	Durch Semikolons getrennte Liste der Eingabecachedateien, aus denen MSBuild Buildergebnisse liest. Wenn -isolateProjects auf False festgelegt ist, wird dies auf True festgelegt.
-interactive[:{True or False}]	Gibt an, dass Aktionen im Build mit dem Benutzer interagieren dürfen. Verwenden Sie dieses Argument nicht in einem automatisierten Szenario, in dem keine Interaktivität erwartet wird. Die Angabe von -interactive ist mit der Angabe von -interactive:true identisch. Verwenden Sie den Parameter, um einen Wert zu überschreiben, der aus einer Antwortdatei stammt.
-isolateProjects[:{True, MessageUponIsolationViolation, False}] -isolate[:{True, MessageUponIsolationViolation, False}]	Führt dazu, dass MSBuild alle Projekte isoliert erstellt. Wenn der Wert auf MessageUponIsolationViolation (oder die Kurzform Message) festgelegt ist, werden nur die Ergebnisse von Zielen der obersten Ebene serialisiert, wenn der Schalter -outputResultsCache übergeben wird. Diese Option besteht darin, die Wahrscheinlichkeit eines isolationsverletzenden Ziels für ein Abhängigkeitsprojekt unter Verwendung eines falschen Zustands aufgrund seiner Abhängigkeit von einem zwischengespeicherten Ziel zu verringern, dessen Nebenwirkungen nicht berücksichtigt werden würden. (Beispielsweise die Definition einer Eigenschaft.) Dieser Modus ist restriktiver, da es erfordert, dass das Projektdiagramm zur Auswertungszeit statisch auffindbar ist, aber die Planung verbessern und den Arbeitsspeicheraufwand beim Erstellen einer großen Gruppe von Projekten verringern kann.
-lowPriority[:{True or False}] -low[:{True or False}]	Bewirkt, dass MSBuild mit niedriger Prozesspriorität ausgeführt wird. Die Angabe von -lowPriority ist mit der Angabe von -lowPriority:True identisch.
-maxCpuCount[:{number}] -m[:{number}]	Gibt die maximale Anzahl gleichzeitiger Prozesse beim Buildvorgang an. Wenn Sie diesen Schalter nicht angeben, wird der Standardwert 1 verwendet. Wenn Sie diesen Switch ohne Angabe eines Werts einschließen, verwendet MSBuild bis zur Anzahl der Prozessoren auf dem Computer. Weitere Informationen finden Sie unter Paralleles Erstellen von mehreren Projekten. Im folgenden Beispiel wird MSBuild angewiesen, drei MSBuild-Prozesse für Buildvorgänge zu nutzen, sodass drei Projekte gleichzeitig erstellt werden können: msbuild myproject.proj -maxcpucount:3
-noAutoResponse -noautorsp	Fügen Sie die Dateien MSBuild.rsp oder Directory.Build.rsp nicht automatisch ein.
-nodeReuse:{value} -nr:{value}	Aktivieren oder deaktivieren Sie die Wiederverwendung von MSBuild-Knoten. Sie können folgende Werte angeben: - TRUE. Nach Abschluss des Buildvorgangs bleiben die Knoten bestehen, sodass sie von nachfolgenden Buildvorgängen genutzt werden können (Standardeinstellung). - FALSE. Nach Abschluss des Buildvorgangs bleiben die Knoten nicht bestehen. Ein Knoten entspricht einem Projekt, das ausgeführt wird. Wenn Sie den -maxcpucount Switch einschließen, können mehrere Knoten gleichzeitig ausgeführt werden.
-nologo	Unterdrückt die Anzeige von Startbanner und Copyrightmeldung.
-preprocess[:{filepath}] -pp[:{filepath}]	Erstellt eine einzelne, aggregierte Projektdatei durch Einbeziehen ("Inlining") sämtlicher Dateien, die während eines Builds importiert werden, unter Angabe ihrer Grenzen. Mithilfe dieses Schalters können Sie leichter feststellen, welche Dateien importiert werden, woher diese Dateien importiert werden und welche Dateien an dem Buildvorgang beteiligt sind. Wenn Sie diesen Schalter verwenden, wird das Projekt nicht erstellt. Wenn Sie einen filepath angeben, wird die aggregierte Projektdatei in die Datei ausgegeben. Andernfalls wird die Ausgabe im Konsolenfenster angezeigt. Wie Sie mithilfe des Import-Elements eine Projektdatei in eine andere Projektdatei einfügen können, wird unter Import-Element (MSBuild) und Vorgehensweise: Verwenden desselben Ziels in mehreren Projektdateien erklärt.
-outputResultsCache[:{cacheFile}] -orc[:{cacheFile}]	Ausgabecachedatei, in der MSBuild den Inhalt seiner Buildergebniscaches am Ende des Builds schreibt. Wenn -isolateProjects auf False festgelegt ist, wird dies auf True festgelegt.
profileEvaluation:{file}	Erstellt ein Profil für die MSBuild-Auswertung und schreibt das Ergebnis in die angegebene Datei. Wenn es sich bei der angegebenen Datei um eine MD-Erweiterung handelt, wird das Ergebnis im Markdownformat generiert. Andernfalls wird eine durch Tabulatoren getrennte Datei erstellt.
-property:{name}={value} -p:{name}={value}	Dient zum Festlegen oder Überschreiben der angegebenen Eigenschaften auf Projektebene. Dabei ist name der Name und value der Wert der Eigenschaft. Geben Sie jede Eigenschaft einzeln an oder verwenden Sie ein Semikolon oder ein Komma, um mehrere Eigenschaften zu trennen (siehe Beispiel): -property:WarningLevel=2;OutDir=bin\Debug Siehe allgemeine MSBuild-Projekteigenschaften für eine Liste häufig verwendeter Eigenschaften. Der vollständige Satz verfügbarer Eigenschaften hängt vom Projekttyp, sdk und importierten Dateien ab.
-restore -r	Führt das Restore-Ziel vor dem Erstellen der eigentlichen Ziele aus.
-restoreProperty:{name}={value} -rp:{name}={value}	Legen Sie diese Eigenschaften auf Projektebene nur während der Wiederherstellung fest oder überschreiben Sie sie, und verwenden Sie keine eigenschaften, die mit dem -property Argument angegeben wurden. name ist der Eigenschaftsname, und value ist der Eigenschaftswert. Geben Sie jede Eigenschaft einzeln an, oder verwenden Sie ein Semikolon oder ein Komma, um mehrere Eigenschaften zu trennen.
-target:{targets} -t:{targets}	Erstellt die angegebenen Ziele im Projekt. Geben Sie jedes Ziel einzeln an oder verwenden Sie ein Semikolon oder ein Komma, um mehrere Ziele zu trennen (siehe Beispiel): -target:PrepareResources;Compile Wenn Sie Ziele mithilfe dieser Option angeben, werden sie anstelle von Zielen im Attribut in der DefaultTargets Projektdatei ausgeführt. Weitere Informationen finden Sie unter Buildreihenfolge für Ziele und Vorgehensweise: Angeben des zuerst zu erstellenden Ziels. Als Ziel wird eine Gruppe von Aufgaben bezeichnet. Weitere Informationen finden Sie unter Ziele.
-targets[:{file}] -ts[:{file}]	Schreibt die Liste der verfügbaren Ziele in die angegebene Datei (oder das Ausgabegerät, wenn keine Datei angegeben wird), ohne den Buildprozess tatsächlich auszuführen.
-toolsVersion:{version} -tv:{version}	Gibt ein benutzerdefiniertes Toolset an. Ein Toolset besteht aus Aufgaben, Zielen und Tools, die beim Erstellen einer Anwendung verwendet werden. Weitere Informationen finden Sie unter Toolset (ToolsVersion) sowie unter Standardmäßige und benutzerdefinierte Toolsetkonfigurationen.
-validate:[{schema}] -val[{schema}]	Überprüft die Projektdatei und erstellt bei erfolgreicher Überprüfung das Projekt. Wenn Sie schema nicht angeben, wird das Projekt anhand des Standardschemas überprüft. Wenn Sie schema angeben, wird das Projekt anhand des angegebenen Schemas überprüft. Die folgende Einstellung ist ein Beispiel: -validate:MyExtendedBuildSchema.xsd
-verbosity:{level} -v:{level}	Gibt den Umfang an Informationen an, die im Buildprotokoll angezeigt werden sollen. Jede Protokollierung zeigt Ereignisse gemäß des Ausführlichkeitsgrads an, den Sie für diese Protokollierung festlegen. Für den Ausführlichkeitsgrad können Sie die folgenden Werte angeben: q[uiet], m[inimal], n[ormal] (Standardwert), d[etailed] und diag[nostic]. Die folgende Einstellung ist ein Beispiel: -verbosity:quiet
-version -ver	Zeigt nur Versionsinformationen an. Das Projekt wird nicht erstellt.
@{file}	Fügt Befehlszeilenschalter aus einer Textdatei ein. Wenn Sie mehrere Dateien haben, müssen Sie diese separat angeben. Weitere Informationen finden Sie unter Antwortdateien.
-warnAsError[:{code; ...}] -err[:{code; ...}]	Liste von Fehlercodes, die als Fehler behandelt werden. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Warnungscodes voneinander zu trennen. Wenn Sie möchten, dass alle Warnungen als Fehler behandelt werden, verwenden Sie den switch-Parameter ohne Werte. Wenn eine Warnung als Fehler behandelt wird, wird das Ziel weiterhin ausgeführt, als wäre es eine Warnung, aber der gesamte Build schlägt fehl. Beispiel: -err:MSB4130
-warnNotAsError[:{code; ...}] -noerr[:{code; ...}]	MSBuild 17.0 und höher. Liste der Warnungscodes, die nicht auf Fehler heraufgestuft werden sollten. Wenn die Option "warnAsError" so festgelegt ist, dass alle Warnungen auf Fehler heraufgestuft werden, werden fehlercodes, die mit warnNotAsError angegeben sind, nicht höhergestuft. Dies hat keine Auswirkung, wenn warnAsError nicht festgelegt ist, um alle Warnungen auf Fehler zu fördern. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Warnungscodes voneinander zu trennen. Beispiel: -noerr:MSB4130
-warnAsMessage[:{code}; ...}] -noWarn[:{code; ...}]	Liste der Warnungscodes, die als Nachrichten mit niedriger Relevanz behandelt werden. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Warnungscodes voneinander zu trennen. Ein Beispiel: -noWarn:MSB3026

Optionen für Protokollierungen

Schalter	Beschreibung
-binaryLogger[:[LogFile=]{output.binlog} [;ProjectImports=None,Embed,ZipFile]] -bl[:[LogFile=]{output.binlog} [;ProjectImports=None,Embed,ZipFile]]	Serialisiert alle Buildereignisse in eine komprimierte Binärdatei. Standardmäßig befindet sich die Datei im aktuellen Verzeichnis und heißt msbuild.binlog. Das binäre Protokoll ist eine ausführliche Beschreibung des Buildprozesses, der später für die Wiederherstellung von Textprotokollen und von weiteren Analysetools verwendet werden kann. Ein binäres Protokoll ist in der Regel zehn- bis zwanzigmal kleiner als die ausführlichste Textprotokoll auf Diagnoseebene. Es enthält aber mehr Informationen. Die binäre Protokollierung erfasst standardmäßig den Quelltext von Projektdateien, einschließlich aller importierten Projekte und Zieldateien, die während des Builds auftreten. Mit dem optionalen ProjectImports Parameter wird dieses Verhalten gesteuert: - ProjectImports=None. Erfassen Sie die Projektimporte nicht. - ProjectImports=Embed. Betten Sie Projektimporte in die Protokolldatei (Standard) ein. - ProjectImports=ZipFile. Speichern Sie Projektdateien in {output}.projectimports.zip , wobei <die Ausgabe> denselben Namen wie der Name der binären Protokolldatei aufweist. Die Standardeinstellung für „ProjectImports“ ist „Einbetten“. Hinweis: Der Logger sammelt keine Nicht-MSBuild-Quelldateien wie .cs, .cppusw. Eine BINLOG-Datei kann „erneut wiedergegeben“ werden, indem sie als Argument statt als Projekt oder Projektmappe an msbuild.exe übergeben wird. Andere Logger erhalten die Informationen, die in der Protokolldatei enthalten sind, als ob der ursprüngliche Build ausgeführt wurde. Weitere Informationen zum Binärprotokoll und dessen Verwendung finden Sie unter https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Binary-Log.md. Beispiele: - -bl - -bl:output.binlog - -bl:output.binlog;ProjectImports=None - -bl:output.binlog;ProjectImports=ZipFile - -bl:..\..\custom.binlog - -binaryLogger
-consoleLoggerParameters:{parameters} -clp:{parameters}	Übergibt die angegebenen Parameter an die Konsolenprotokollierung, die Buildinformationen im Konsolenfenster anzeigt. Sie können die folgenden Parameter angeben: - PerformanceSummary. Zeigt die Zeitdauer bei der Arbeit an Aufgaben, Zielen und Projekten an - Summary. Zeigt am Ende eine Zusammenfassung zu aufgetretenen Fehlern und Warnungen an. - NoSummary. Am Ende wird keine Zusammenfassung zu aufgetretenen Fehlern und Warnungen angezeigt. - ErrorsOnly. Nur Fehler werden angezeigt. - WarningsOnly. Nur Warnungen werden angezeigt. - NoItemAndPropertyList. Unterdrückt die Anzeige der Liste von Elementen und Eigenschaften, die zu Beginn jedes Projekts angezeigt wird, wenn der Ausführlichkeitsgrad auf diagnostic festgelegt ist. - ShowCommandLine. Zeigt TaskCommandLineEvent-Meldungen an. - ShowProjectFile. Zeigt den Pfad zur Projektdatei in Diagnosenachrichten an. Diese Einstellung ist standardmäßig eingeschaltet. - ShowTimestamp. Stellt jeder Meldung den zugehörigen Zeitstempel voran. - ShowEventId. Zeigt zu jedem Ereignis vom Typ "Gestartet" und "Abgeschlossen" sowie zu jeder Meldung die Ereignis-ID an. - ForceNoAlign. Hierbei wird der Text nicht der Größe des Konsolenpuffers angeglichen. - DisableConsoleColor. Verwendet bei allen Protokollierungsmeldungen die Standardkonsolenfarben. - DisableMPLogging. Deaktiviert bei Ausführung im Einzelprozessormodus das Multiprozessor-Protokollierungsformat der Ausgabe. - EnableMPLogging. Aktiviert das Multiprozessor-Protokollierungsformat auch bei Ausführung im Einzelprozessormodus. Dieses Protokollierungsformat ist standardmäßig aktiviert. - ForceConsoleColor Verwenden Sie ANSI-Konsolenfarben, auch wenn die Konsole sie nicht unterstützt. - Verbosity. Überschreiben Sie die -verbosity Einstellung für diesen Logger. Mehrere Parameter sind mit einem Semikolon zu trennen, wie im folgenden Beispiel gezeigt: -consoleLoggerParameters:PerformanceSummary;NoSummary -verbosity:minimal Standardmäßig ist die Konsolenprotokollierung auf eine normale Ausführlichkeit festgelegt und beinhaltet Summary.
-distributedFileLogger -dfl	Protokolliert die Buildausgabe jedes MSBuild-Knotens in dessen eigene Datei. In der Standardeinstellung werden diese Dateien im aktuellen Verzeichnis gespeichert. Standardmäßig heißen die Dateien MSBuild{NodeId}.log. Mit der -fileLoggerParameters Option können Sie den Speicherort der Dateien und andere Parameter für den FileLogger angeben. Wenn Sie eine Protokolldatei mithilfe der -fileLoggerParameters Option benennen, verwendet der verteilte Logger diesen Namen als Vorlage und fügt die Knoten-ID beim Erstellen einer Protokolldatei für jeden Knoten an diesen Namen an.
-distributedLogger:{central logger},{forwarding logger}, ... -dl:{central logger},{forwarding logger, ...}	Protokolliert Ereignisse von MSBuild und hängt an jeden Knoten eine andere Protokollierungsinstanz an. Wenn Sie mehrere Protokollierungen angeben möchten, müssen Sie jede Protokollierung einzeln angeben. Sie verwenden die Loggersyntax, um einen Logger anzugeben, mit Ausnahme der Bereitstellung und zusätzlicher Klasse für den Weiterleitungsprotokollierer. Informationen zur Loggersyntax finden Sie in der -logger Option. Das folgende Beispiel zeigt, wie dieser Schalter verwendet wird: -dl:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral -dl:MyLogger,C:\My.dll*ForwardingLogger,C:\Logger.dll
-fileLogger[{number}] -fl[{number}]	Protokolliert die Buildausgabe in einer einzelnen Datei im aktuellen Verzeichnis. Wenn Sie number nicht angeben, erhält die Ausgabedatei den Namen msbuild.log. Wenn Sie number angeben, erhält die Ausgabedatei den Namen msbuild<n>.log. Hierbei steht <n> für number. Number kann eine Ziffer von 1 bis 9 sein. Mit der -fileLoggerParameters Option können Sie den Speicherort der Datei und andere Parameter für den FileLogger angeben.
-fileLoggerParameters[{number}]: parameters -flp[{number}]: {parameters}	Dient zur Angabe aller sonstigen Parameter für die Dateiprotokollierung und die verteilte Dateiprotokollierung. Das Vorhandensein dieser Option impliziert, dass der entsprechende -filelogger[number] Schalter vorhanden ist. Number kann eine Ziffer von 1 bis 9 sein. Sie können alle Parameter verwenden, die für -consoleloggerparameters. Sie können auch einen oder mehrere der folgenden Parameter verwenden: - LogFile. Gibt den Pfad zu der Protokolldatei an, in die das Buildprotokoll geschrieben wird. Die verteilte Dateiprotokollierung stellt diesen Pfad den Namen seiner Protokolldateien voran. - Append. Bestimmt, ob das Buildprotokoll an die Protokolldatei angefügt wird oder diese überschreibt. Wenn Sie den Schalter setzen, wird das Buildprotokoll an die Protokolldatei angefügt. Wenn der Switch nicht vorhanden ist, werden die Inhalte einer vorhandenen Protokolldatei überschrieben. Beispiel: msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log;append Wenn Sie eine explizite true- oder false-Einstellung einschließen, wird das Protokoll unabhängig von der Einstellung angefügt. Wenn Sie den Anfügeschalter nicht einschließen, wird das Protokoll überschrieben. In diesem Fall wird die Datei überschrieben: msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log In diesem Fall wird die Datei angefügt: msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log;append=true In diesem Fall wird die Datei angefügt: msbuild myfile.proj -flp:FileLogger,Microsoft.Build;logfile=MyLog.log;append=false - Encoding. Gibt die Codierung für die Datei an (z. B. UTF-8, Unicode oder ASCII). Das folgende Beispiel generiert separate Protokolldateien für Warnungen und Fehler: -flp1:logfile=errors.txt;errorsonly -flp2:logfile=warnings.txt;warningsonly Die folgenden Beispiele zeigen weitere Möglichkeiten: -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	Gibt die Protokollierung an, mit der Ereignisse aus MSBuild protokolliert werden sollen. Wenn Sie mehrere Protokollierungen angeben möchten, müssen Sie jede Protokollierung einzeln angeben. Verwenden Sie bei logger die folgende Syntax: [LoggerClass,]LoggerAssembly[;LoggerParameters] Verwenden Sie bei LoggerClass die folgende Syntax: [PartialOrFullNamespace.]LoggerClassName Wenn die Assembly genau eine Protokollierung enthält, muss die Protokollierungsklasse nicht angegeben werden. Verwenden Sie bei LoggerAssembly die folgende Syntax: AssemblyName[,StrongName] \| AssemblyFile Protokollierungsparameter sind optional und werden so an die Protokollierung übergeben, wie Sie sie eingegeben würden. In den folgenden Beispielen wird die -logger Option verwendet. -logger:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral -logger:XMLLogger,C:\Loggers\MyLogger.dll;OutputAsHTML
-noConsoleLogger -noconlog	Deaktiviert die standardmäßige Konsolenprotokollierung und protokolliert keine Ereignisse in der Konsole.
-terminalLogger[:auto,on,off] -tl[:auto,on,off]	Aktivieren oder deaktivieren Sie den Terminalprotokollierer. Terminal logger bietet eine verbesserte Buildausgabe auf der Konsole in Echtzeit, logisch nach Projekt organisiert und entwickelt, um umsetzbare Informationen hervorzuheben. Geben Sie an (oder verwenden Sie auto die Option ohne Argumente), um den Terminalprotokollierer nur dann zu verwenden, wenn die Standardausgabe nicht umgeleitet wird. Analysieren Sie die Ausgabe nicht, oder verlassen Sie sich auf sie, die in zukünftigen Versionen unverändert bleiben. Diese Option ist in MSBuild 17.8 und höher verfügbar.

Beispiel

Im folgenden Beispiel wird das rebuild-Ziel des Projekts MyProject.proj erstellt.

MSBuild.exe MyProject.proj -t:rebuild

Siehe auch

• MSBuild-Referenz
• Gemeinsame MSBuild-Projekteigenschaften