MSBuild-Befehlszeilenreferenz

Artikel
01/28/2025

Wenn Sie MSBuild.exe verwenden, um eine Projekt- oder Lösungsdatei zu erstellen, können Sie mehrere Schalter einschließen, um verschiedene Aspekte des Prozesses anzugeben.

Jeder Schalter ist in zwei Formen verfügbar: -switch und /switch. In der Dokumentation wird nur das formular -switch angezeigt. Bei Schaltern wird die Groß-/Kleinschreibung nicht beachtet. Wenn Sie MSBuild aus einer anderen Shell als der Windows-Eingabeaufforderung ausführen, benötigen Listen von Argumenten zu einem Schalter (getrennt durch Semikolons oder Kommas) möglicherweise einzelne oder doppelte Anführungszeichen, um sicherzustellen, dass Listen an MSBuild übergeben werden, anstatt von der Shell interpretiert zu werden.

Die .NET CLI-Befehle dotnet build, dotnet publish, dotnet msbuild and related commands pass these switches to MSBuild, so this reference is applicable when you use these commands; dotnet run jedoch nicht.

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 Dateinamenerweiterung, die auf proj- endet und diese Datei verwendet. Sie können auch eine Visual Studio-Projektmappendatei für dieses 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 [] optionale Teile und geschweifte Klammern {}angeben, die vom Benutzer bereitgestellte Werte angeben.

Schalter	Beschreibung
`-detailedSummary[:{True or False}]` `-ds[:{True or False}]`	Wenn `True`, zeigen Sie detaillierte Informationen am Ende des Buildprotokolls zu den konfigurationen an, die erstellt wurden und wie sie für Knoten geplant wurden.
`-getItem:{itemName,...}`	Notieren Sie den Wert des Elements oder der Elemente nach der Auswertung, ohne den Build auszuführen, oder wenn entweder die option `-targets` oder die option `-getTargetResult` verwendet wird, schreiben Sie die Werte nach dem Build aus.
`-getProperty:{propertyName,...}`	Notieren Sie den Wert der Eigenschaft oder eigenschaften nach der Auswertung, ohne den Build auszuführen, oder wenn entweder die option `-targets` oder die option `-getTargetResult` verwendet wird, schreiben Sie die Werte nach dem Build aus.
`-getTargetResult:{targetName,...}`	Schreiben Sie die Ausgabewerte der angegebenen Ziele aus.
`-graphBuild[:{True or False}]` `-graph[:{True or False}]`	Bewirkt, dass MSBuild ein Projektdiagramm erstellt und erstellt. Das Erstellen eines Diagramms umfasst das Identifizieren von Projektbezügen auf Formularabhängigkeiten. Das Erstellen dieses Diagramms umfasst den Versuch, Projektverweise vor den Projekten zu erstellen, die darauf verweisen, und unterscheidet sich von der herkömmlichen MSBuild-Planung. Erfordert MSBuild 16 oder höher.
`-help` `/?` oder `-h`	Verwendungsinformationen anzeigen. Der folgende Befehl ist ein Beispiel: `msbuild.exe -?`
`-ignoreProjectExtensions: {extensions}` `-ignore: {extensions}`	Ignorieren Sie die angegebenen Erweiterungen, wenn Sie bestimmen, welche Projektdatei erstellt werden soll. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Erweiterungen zu trennen, 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 sie 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 Interaktivität nicht erwartet wird. Das Angeben von `-interactive` entspricht dem Angeben von `-interactive:true`. Verwenden Sie den Parameter, um einen Wert außer Kraft zu setzen, der aus einer Antwortdatei stammt.
`-isolateProjects[:{True, MessageUponIsolationViolation, False}]` `-isolate[:{True, MessageUponIsolationViolation, False}]`	Bewirkt, dass MSBuild jedes Projekt isoliert erstellt. Bei Festlegung auf `MessageUponIsolationViolation` (oder deren kurze Form `Message`) werden nur die Ergebnisse von Zielen der obersten Ebene serialisiert, wenn der `-outputResultsCache` Switch bereitgestellt 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 bei niedriger Prozesspriorität ausgeführt wird. Das Angeben von `-lowPriority` entspricht dem Angeben von `-lowPriority:True`.
`-maxCpuCount[:{number}]` `-m[:{number}]`	Gibt die maximale Anzahl gleichzeitiger Prozesse an, die beim Erstellen verwendet werden sollen. Wenn Sie diesen Schalter nicht einschließen, ist der Standardwert 1. 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 Erstellen mehrerer Projekte parallel. Im folgenden Beispiel wird MSBuild angewiesen, mit drei MSBuild-Prozessen zu erstellen, wodurch drei Projekte gleichzeitig erstellt werden können: `msbuild myproject.proj -maxcpucount:3`
`-noAutoResponse` `-noautorsp`	Fügen Sie keine MSBuild.rsp oder Directory.Build.rsp Dateien automatisch ein.
`-nodeReuse:{value}` `-nr:{value}`	Aktivieren oder deaktivieren Sie die Wiederverwendung von MSBuild-Knoten. Sie können die folgenden Werte angeben: - True. Knoten verbleiben nach Abschluss des Builds, sodass nachfolgende Builds sie verwenden können (Standard). - False. Knoten bleiben nach Abschluss des Builds nicht mehr 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`	Zeigen Sie nicht das Startbanner oder die Copyrightnachricht an.
`-preprocess[:{filepath}]` `-pp[:{filepath}]`	Erstellen Sie eine einzelne aggregierte Projektdatei, indem Sie alle Dateien angibt, die während eines Builds importiert würden, wobei ihre Grenzen markiert sind. Sie können diesen Switch verwenden, um einfacher zu bestimmen, welche Dateien importiert werden, aus dem die Dateien importiert werden, und welche Dateien zum Build beitragen. Wenn Sie diese Option verwenden, wird das Projekt nicht erstellt. Wenn Sie eine `filepath`angeben, wird die aggregierte Projektdatei in die Datei ausgegeben. Andernfalls wird die Ausgabe im Konsolenfenster angezeigt. Informationen zum Verwenden des `Import` Elements zum Einfügen einer Projektdatei in eine andere Projektdatei finden Sie unter Import-Element (MSBuild) und How to: Use the same target in multiple project files.
`-outputResultsCache[:{cacheFile}]` `-orc[:{cacheFile}]`	Ausgabecachedatei, in der MSBuild den Inhalt seiner Buildergebniscaches am Ende des Builds schreibt. Wenn `-isolateProjects` auf `False`festgelegt ist, wird sie auf `True`festgelegt.
`profileEvaluation:{file}`	Profile MSBuild-Auswertung und schreibt das Ergebnis in die angegebene Datei. Wenn die Erweiterung der angegebenen Datei ".md" lautet, wird das Ergebnis im Markdown-Format generiert. Andernfalls wird eine durch Tabstopp getrennte Datei erstellt.
`-property:{name}={value}` `-p:{name}={value}`	Legen Oder überschreiben Sie die angegebenen Eigenschaften auf Projektebene, wobei `name` der Eigenschaftenname ist und `value` der Eigenschaftswert ist. Geben Sie jede Eigenschaft separat an, oder verwenden Sie ein Semikolon oder Komma, um mehrere Eigenschaften zu trennen, wie das folgende Beispiel zeigt: `-property:WarningLevel=2;OutDir=bin\Debug` Eine Liste der häufig verwendeten Eigenschaften finden Sie unter allgemeinen MSBuild-Projekteigenschaften. 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 tatsächlichen 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. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Eigenschaften zu trennen, oder geben Sie jede Eigenschaft separat an.
`-target:{targets}` `-t:{targets}`	Erstellen Sie die angegebenen Ziele im Projekt. Geben Sie jedes Ziel separat an, oder verwenden Sie ein Semikolon oder Komma, um mehrere Ziele zu trennen, wie das folgende Beispiel zeigt: `-target:PrepareResources;Compile` Wenn Sie Ziele mithilfe dieser Option angeben, werden sie anstelle von Zielen im attribut `DefaultTargets` in der Projektdatei ausgeführt. Weitere Informationen finden Sie unter Zielbuildreihenfolge und How to: Specify which target to build first. Ein Ziel ist eine Gruppe von Aufgaben. Weitere Informationen finden Sie unter Targets.
`-targets[:{file}]` `-ts[:{file}]`	Schreiben Sie die Liste der verfügbaren Ziele in die angegebene Datei (oder das Ausgabegerät, wenn keine Datei angegeben ist), ohne den Buildvorgang tatsächlich auszuführen.
`-toolsVersion:{version}` `-tv:{version}`	Gibt ein benutzerdefiniertes Toolset an. Ein Toolset besteht aus Aufgaben, Zielen und Tools, die zum Erstellen einer Anwendung verwendet werden. Siehe Toolset (ToolsVersion) und Standard- und benutzerdefinierten Toolsetkonfigurationen.
`-validate:[{schema}]` `-val[{schema}]`	Überprüfen Sie die Projektdatei, und erstellen Sie, wenn die Überprüfung erfolgreich ist, das Projekt. Wenn Sie `schema`nicht angeben, wird das Projekt anhand des Standardschemas überprüft. Wenn Sie `schema`angeben, wird das Projekt anhand des von Ihnen angegebenen Schemas überprüft. Die folgende Einstellung ist ein Beispiel: `-validate:MyExtendedBuildSchema.xsd`
`-verbosity:{level}` `-v:{level}`	Gibt die Menge der Informationen an, die im Buildprotokoll angezeigt werden sollen. Jeder Logger zeigt Ereignisse basierend auf der Ausführlichkeitsebene an, die Sie für diesen Logger festgelegt haben. Sie können die folgenden Ausführlichkeitsebenen angeben: `q[uiet]`, `m[inimal]`, `n[ormal]` (Standard), `d[etailed]`und `diag[nostic]`. Die folgende Einstellung ist ein Beispiel: `-verbosity:quiet`
`-version` `-ver`	Nur Versionsinformationen anzeigen. Das Projekt wird nicht erstellt.
`@{file}`	Befehlszeilenoptionen aus einer Textdatei einfügen. Wenn Sie über mehrere Dateien verfügen, geben Sie sie separat an. Weitere Informationen finden Sie unter Antwortdateien.
`-warnAsError[:{code; ...}]` `-err[:{code; ...}]`	Liste der Warnungscodes, die als Fehler behandelt werden sollen. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Warnungscodes zu trennen. Um alle Warnungen als Fehler zu behandeln, verwenden Sie den Schalter 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 zu trennen. Beispiel: `-noerr:MSB4130`
`-warnAsMessage[:{code}; ...}]` `-noWarn[:{code; ...}]`	Liste der Warnungscodes, die als Nachrichten mit niedriger Wichtigkeit behandelt werden sollen. Verwenden Sie ein Semikolon oder ein Komma, um mehrere Warnungscodes zu trennen. Beispiel: `-noWarn:MSB3026`

Schalter für Logger

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 detaillierte Beschreibung des Buildprozesses, die später verwendet werden kann, um Textprotokolle zu rekonstruieren und von anderen Analysetools verwendet zu werden. Ein binäres Protokoll ist in der Regel 10-20x kleiner als das detaillierteste Textdiagnoseprotokoll, enthält jedoch weitere Informationen. Der binäre Logger sammelt standardmäßig den Quelltext von Projektdateien, einschließlich aller importierten Projekte und Zieldateien, die während des Builds aufgetreten sind. Der optionale `ProjectImports` Parameter steuert dieses Verhalten: - ProjectImports=None. Sammeln Sie die Projektimporte nicht. - ProjectImports=Embed. Einbetten von Projektimporten in die Protokolldatei (Standardeinstellung). - ProjectImports=ZipFile. Speichern Sie Projektdateien in {output}-.projectimports.zip, wobei <Ausgabe-> denselben Namen wie der Name der binären Protokolldatei aufweist. Die Standardeinstellung für ProjectImports ist Embed. Hinweis: Der Logger sammelt keine Nicht-MSBuild-Quelldateien wie `.cs`, `.cpp`usw. Ein BINLOG- Datei kann durch Übergeben an msbuild.exe als Argument anstelle eines Projekts/einer Projektmappe "wiedergegeben" werden. Andere Logger erhalten die Informationen, die in der Protokolldatei enthalten sind, als ob der ursprüngliche Build ausgeführt wurde. Weitere Informationen zum binären Protokoll und deren 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}`	Übergeben Sie die Parameter, die Sie an den Konsolenprotokollierer angeben, der Buildinformationen im Konsolenfenster anzeigt. Sie können die folgenden Parameter angeben: - PerformanceSummary. Zeigen Sie die Zeit an, die in Vorgängen, Zielen und Projekten aufgewendet wird. - Zusammenfassung. Zeigen Sie die Fehler- und Warnungszusammenfassung am Ende an. - NoSummary. Zeigen Sie nicht die Fehler- und Warnungszusammenfassung am Ende an. - ErrorsOnly. Nur Fehler anzeigen. - WarningsOnly. Nur Warnungen anzeigen. - NoItemAndPropertyList. Zeigen Sie nicht die Liste der Elemente und Eigenschaften an, die zu Beginn jedes Projektbuilds angezeigt werden, wenn die Ausführlichkeitsebene auf `diagnostic`festgelegt ist. - ShowCommandLine-. `TaskCommandLineEvent` Nachrichten anzeigen. - ShowProjectFile-. Zeigen Sie den Pfad zur Projektdatei in Diagnosemeldungen an. Diese Einstellung ist standardmäßig aktiviert. - ShowTimestamp-. Zeigt den Zeitstempel als Präfix für jede Nachricht an. - ShowEventId-. Zeigt die Ereignis-ID für jedes gestartete Ereignis, das fertige Ereignis und die Nachricht an. - ForceNoAlign. Richten Sie den Text nicht an der Größe des Konsolenpuffers aus. - DisableConsoleColor. Verwenden Sie die Standardkonsolenfarben für alle Protokollierungsmeldungen. - DisableMPLogging-. Deaktivieren Sie den Ausgabestil für die Multiprozessorprotokollierung, wenn sie im Modus ohne Multiprozessor ausgeführt wird. - EnableMPLogging-. Aktivieren Sie den Multiprozessorprotokollierungsstil auch dann, wenn er im Modus ohne Multiprozessor ausgeführt wird. Dieser Protokollierungsstil ist standardmäßig aktiviert. - ForceConsoleColor. Verwenden Sie ANSI-Konsolenfarben, auch wenn die Konsole sie nicht unterstützt. - Verbosity. Überschreiben Sie die einstellung `-verbosity` für diesen Logger. Verwenden Sie ein Semikolon, um mehrere Parameter zu trennen, wie im folgenden Beispiel gezeigt: `-consoleLoggerParameters:PerformanceSummary;NoSummary -verbosity:minimal` Der Standardkonsolenprotokollierer befindet sich in normaler Ausführlichkeit und enthält eine `Summary`.
`-distributedFileLogger` `-dfl`	Protokollieren Sie die Buildausgabe jedes MSBuild-Knotens in einer eigenen Datei. Der ursprüngliche Speicherort für diese Dateien ist das aktuelle Verzeichnis. Standardmäßig werden die Dateien MSBuild{NodeId}.logbenannt. Sie können die option `-fileLoggerParameters` verwenden, um den Speicherort der Dateien und andere Parameter für den FileLogger anzugeben. Wenn Sie eine Protokolldatei mithilfe der option `-fileLoggerParameters` benennen, verwendet der verteilte Logger diesen Namen als Vorlage und fügt die Knoten-ID an diesen Namen an, wenn sie eine Protokolldatei für jeden Knoten erstellen.
`-distributedLogger:{central logger},{forwarding logger}, ...` `-dl:{central logger},{forwarding logger, ...}`	Protokollieren Sie Ereignisse von MSBuild, und fügen Sie eine andere Loggerinstanz an jeden Knoten an. Wenn Sie mehrere Logger angeben möchten, geben Sie jeden Logger separat an. 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 im `-logger` Switch. Die folgenden Beispiele zeigen, wie Sie diesen Schalter verwenden: `-dl:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral` `-dl:MyLogger,C:\My.dll*ForwardingLogger,C:\Logger.dll`
`-fileLogger[{number}]` `-fl[{number}]`	Protokollieren Sie die Buildausgabe in einer einzelnen Datei im aktuellen Verzeichnis. Wenn Sie `number`nicht angeben, wird die Ausgabedatei msbuild.logbenannt. Wenn Sie `number`angeben, wird die Ausgabedatei msbuild<n>.logbenannt, wobei <n>`number`ist. `Number` kann eine Ziffer zwischen 1 und 9 sein. Sie können die option `-fileLoggerParameters` verwenden, um den Speicherort der Datei und andere Parameter für den fileLogger anzugeben.
`-fileLoggerParameters[{number}]:` `parameters` `-flp[{number}]: {parameters}`	Gibt alle zusätzlichen Parameter für den Dateiprotokollierer und den verteilten Dateiprotokollierer an. Das Vorhandensein dieses Schalters impliziert, dass der entsprechende `-filelogger[number]` Schalter vorhanden ist. `Number` kann eine Ziffer zwischen 1 und 9 sein. Sie können alle Parameter verwenden, die für `-consoleloggerparameters`aufgelistet sind. Sie können auch einen oder mehrere der folgenden Parameter verwenden: - LogFile-. Der Pfad zur Protokolldatei, in die das Buildprotokoll geschrieben wird. Der verteilte Dateilogger stellt diesem Pfad die Namen seiner Protokolldateien voran. - anfügen. Bestimmt, ob das Buildprotokoll an die Protokolldatei angefügt oder überschrieben wird. Wenn Sie den Switch festlegen, 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` - Codierung. Gibt die Codierung für die Datei an (z. B. UTF-8, Unicode oder ASCII). Im folgenden Beispiel werden separate Protokolldateien für Warnungen und Fehler generiert: `-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 den Logger an, der zum Protokollieren von Ereignissen von MSBuild verwendet werden soll. Wenn Sie mehrere Logger angeben möchten, geben Sie jeden Logger separat an. Verwenden Sie die folgende Syntax für `logger`: `[LoggerClass,]LoggerAssembly[;LoggerParameters]` Verwenden Sie die folgende Syntax für `LoggerClass`: `[PartialOrFullNamespace.]LoggerClassName` Sie müssen die Loggerklasse nicht angeben, wenn die Assembly genau einen Logger enthält. Verwenden Sie die folgende Syntax für `LoggerAssembly`: `AssemblyName[,StrongName] \\| AssemblyFile` Loggerparameter sind optional und werden genau beim Eingeben an den Logger übergeben. In den folgenden Beispielen wird der Schalter `-logger` verwendet. `-logger:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral` `-logger:XMLLogger,C:\Loggers\MyLogger.dll;OutputAsHTML`
`-noConsoleLogger` `-noconlog`	Deaktivieren Sie den Standardkonsolenprotokollierer, und protokollieren Sie 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 `auto` an (oder verwenden Sie die Option ohne Argumente), um den Terminalprotokollierer nur 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 MyProject.proj Projekts erstellt.

MSBuild.exe MyProject.proj -t:rebuild

Freigeben über

MSBuild-Befehlszeilenreferenz

Syntax

Argumente

Schalter

Schalter für Logger

Beispiel

Siehe auch

Feedback

Zusätzliche Ressourcen