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 Varianten verfügbar: -schalter und /schalter. In der Dokumentation wird nur die Form „-schalter“ gezeigt. Bei Schaltern wird nicht zwischen Groß–/Kleinschreibung unterschieden. 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 -ds Zeigt am Ende des Buildprotokolls ausführliche Informationen zu den erstellten Konfigurationen und deren Planung in Knoten an.
-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
-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 False] -isolate[:True oder False] Führt dazu, dass MSBuild alle Projekte isoliert erstellt. Hierbei handelt es sich um einen restriktiveren MSBuild-Modus, da für ihn erforderlich ist, dass der Projektgraph bei der Auswertung statisch erkennbar ist. Der Modus kann die Zeitplanung optimieren und den Arbeitsspeicheraufwand reduzieren, wenn viele Projekte erstellt werden.
-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 Schalter ohne Angabe eines Werts verwenden, nutzt MSBuild alle Prozessoren des Computers. 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 Schließen Sie keine MSBUILD.RSP-Dateien automatisch ein.
-nodeReuse:value -nr:value Aktiviert oder deaktiviert 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] Die Ausgabecachedatei, in die MSBuild am Ende des Builds die Inhalte des Buildergebnicaches schreibt. Wenn dieser switch-Parameter festgelegt wird, werden dadurch auch isolierte Builds (-isolate) aktiviert.
-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 Das Festlegen und Überschreiben dieser Eigenschaften auf Projektebene sollte nur während Wiederherstellungsvorgängen erfolgen, und verwenden Sie nicht die Eigenschaften, die vom -property-Argument angegeben werden. 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 über diesen Schalter Ziele angeben, werden diese anstelle der im DefaultTargets-Attribut in der Projektdatei angegebenen Ziele 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 die Version des Toolsets an, mit dem das Projekt erstellt werden soll, wie zum Beispiel: -toolsversion:3.5

Wenn Sie diese Option verwenden, können Sie ein Projekt mit einer anderen Version als der im Project-Element (MSBuild) festgelegten erstellen. Weitere Informationen erhalten Sie unter Überschreiben der ToolsVersion-Einstellungen.

Bei MSBuild 4.5 können Sie für version die folgenden Werte angeben: 2.0, 3.5 und 4.0. Wenn Sie 4.0 angeben, gibt die Buildeigenschaft VisualStudioVersion an, welches Unter-Toolset verwendet werden soll. Weitere Informationen finden Sie im Abschnitt zu Unter-Toolsets unter Toolset (ToolsVersion).

Ein Toolset besteht aus Aufgaben, Zielen und Tools, die beim Erstellen einer Anwendung verwendet werden. Zu den Tools zählen Compiler wie csc.exe und vbc.exe. Weitere Informationen zu Toolsets finden Sie unter Toolset (ToolsVersion), Standardmäßige und benutzerdefinierte Toolsetkonfigurationen und Festlegung von Zielversionen. Hinweis: Die Toolsetversion ist nicht das gleiche wie das Zielframework – dieses ist die Version von .NET Framework, auf der das zu erstellende Projekt ausgeführt werden soll. Weitere Informationen finden Sie unter Zielframework und -Zielplattform.
-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 weiter ausgeführt, als würde es sich um eine Warnung handeln, aber der gesamte Build schlägt fehl.

Ein Beispiel: -err: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 <output>.projectimports.zip. Hierbei entspricht <output> dem Namen der binären Protokolldatei.

Die Standardeinstellung für „ProjectImports“ ist „Einbetten“.
Hinweis: Die Protokollierung erfasst keine Nicht-MSBuild-Quelldateien wie CS- und CPP-Dateien.
Eine BINLOG-Datei kann „erneut wiedergegeben“ werden, indem sie als Argument statt als Projekt oder Projektmappe an msbuild.exe übergeben wird. Andere Protokollierungen erhalten die in der Protokolldatei enthaltenen Informationen, als ob der ursprüngliche Build erstellt würde. 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.
- 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.
- 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 Schalters -fileLoggerParameters benennen, wird die verteilte Protokollierung diesen Namen als Vorlage verwenden und die Knoten-ID an ihn anfügen, wenn sie eine Protokolldatei für jeden Knoten erstellt.
-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.

Zum Angeben einer Protokollierung verwenden Sie die Protokollierungssyntax. Informationen zur Protokollierungssyntax finden Sie weiter unten unter dem Schalter -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 (wobei <n> für die in number angegebene Nummer steht). 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[Nummer]:

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 Schalter nicht angegeben ist, wird der Inhalt einer vorhandenen Protokolldatei überschrieben.
Ein 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 der Schalter nicht vorhanden ist, 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``] &#124; 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.

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

Siehe auch