MSBuild-Befehlszeilenreferenz

Artikel
03/10/2023

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 Varianten verfügbar: -schalter und /schalter. In der Dokumentation wird nur die Form „-schalter“ 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.

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

Schalter	Kurzform	Beschreibung
-detailedSummary[:`True` oder `False`]	-ds[:`True` oder `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` oder `False`]	-graph[:`True` oder `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`[`;cacheFile2`]	-irc[:`cacheFile`[`;cacheFile2`]	Durch Semikolons getrennte Liste der Eingabecachedateien, aus denen MSBuild Buildergebnisse liest. Wenn `-isolateProjects` auf `False` festgelegt ist, wird dies auf `True` festgelegt.
-interactive[:`True` oder `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. Das Angeben von -interactive ist identisch mit dem Angeben von -interactive:true. Verwenden Sie den Parameter, um einen Wert zu überschreiben, der aus einer Antwortdatei stammt.
-isolateProjects[:`True` oder `MessageUponIsolationViolation` oder `False`]	-isolate[:`True` oder `MessageUponIsolationViolation` oder `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 Schalter -maxcpucount angeben, 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`
-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 Argument "-property" 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`[`;code2`]	-err[`:code`[`;code2`]	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`[`;code2`]	-noerr[`:code`[`;code2`]	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. Ein Beispiel: `-noerr:MSB4130`
-warnAsMessage[:`code`[`;code2`]	-noWarn[:`code`[`;code2`]	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	Kurzform	Beschreibung
-binaryLogger[:[LogFile=]`output.binlog` [;ProjectImports=[None,Embed,ZipFile]]]	-bl	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. Der optionale Schalter `ProjectImports` steuert dieses Verhalten: - ProjectImports=None. Erfassen Sie die Projektimporte nicht. - ProjectImports=Embed. Betten Sie Projektimporte in die Protokolldatei (Standard) ein. - ProjectImports=ZipFile. Speichern Sie Projektdateien in <Ausgabe>.projectimports.zip. Hierbei entspricht <Ausgabe> dem Namen der binären Protokolldatei. Die Standardeinstellung für „ProjectImports“ ist „Einbetten“. Hinweis: Der Logger sammelt keine Nicht-MSBuild-Quelldateien wie .cs, .cpp usw. 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. Überschreibt die Einstellung -verbosity für diese Protokollierung. 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. Die Namen der Dateien lauten standardmäßig MSBuild<NodeId>.log. Sie können den Schalter -fileLoggerParameters verwenden, um den Speicherort der Dateien und andere Parameter für „fileLogger“ anzugeben. Wenn Sie eine Protokolldatei mithilfe des Switchs "-fileLoggerParameters " 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 loggerforwarding 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. Zum Angeben einer Protokollierung verwenden Sie die Protokollierungssyntax. Die Loggersyntax finden Sie unter der Option "-logger ". 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. Sie können den Schalter -fileLoggerParameters verwenden, um den Speicherort der Datei und andere Parameter für „fileLogger“ anzugeben.
-fileLoggerParameters[`number`]: `parameters`	-flp[ `number`]: `parameters`	Dient zur Angabe aller sonstigen Parameter für die Dateiprotokollierung und die verteilte Dateiprotokollierung. Bei Angabe dieses Schalters wird davon ausgegangen, dass der zugehörige -filelogger[`number`] -Schalter vorhanden ist. `Number` kann eine Ziffer von 1 bis 9 sein. Sie können alle Parameter verwenden, die für -consoleloggerparameters aufgeführt werden. 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 der -logger-Schalter 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`,,`offon`]	-tl[:`auto`,,`offon`]	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 anderweitig darauf Standard in zukünftigen Versionen unverändert. Diese Option ist in MSBuild 17.8 und höher verfügbar.

Beispiel 1

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

MSBuild.exe MyProject.proj -t:rebuild

Beispiel 2

Mit MSBuild.exe sind auch komplexere Builds möglich. So können Sie das Tool zum Beispiel verwenden, um bestimmte Ziele von bestimmten Projekten in einer Projektmappe zu erstellen. Im folgenden Beispiel wird das Projekt NotInSolutionFolder neu erstellt, und das Projekt InSolutionFolder, das sich im Projektmappenordner NewFolder befindet, wird gelöscht.

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