Freigeben über

MSBuild- und Visual Studio-Format für Diagnosenachrichten

  • Artikel

Wenn ein Tool ausgeführt wird, das Text ausgibt, überprüft MSBuild den Text auf Fehler und Warnungen. Viele Tools verwenden ein bekanntes Format, um diese Nachrichten auszugeben. Standardmäßig untersucht MSBuild den Text und meldet Fehler und/oder Warnungen basierend auf der Ausgabe. Dieses Verhalten kann mithilfe dieser Parameter für Task Exec geändert oder deaktiviert werden: IgnoreStandardErrorWarningFormat, CustomErrorRegularExpression und CustomWarningRegularExpression.

Hinweis

Wenn Sie einen eigenen regulären Ausdruck verwenden möchten, um Fehler und Warnungen zu erkennen, sollten Sie beachten, dass MSBuild das Ergebnis Zeile für Zeile überprüft. Wenn Ihr benutzerdefinierter regulärer Ausdruck einen Abgleich über mehrere Zeilen enthält, funktioniert dieser nicht wie beabsichtigt, da MSBuild den Text verarbeitet.

Sehen Sie sich die folgenden vier Nachrichten an, die alle ordnungsgemäß formatiert sind und von MSBuild und Microsoft Visual Studio erkannt werden:

Main.cs(17,20): warning CS0168: The variable 'x' is declared but never used
C:\dir1\strings.resx(2) : error BC30188: Declaration expected.
cl : Command line warning D4024 : unrecognized source file type 'file1.cs', object . . .
error CS0006: Metadata file 'System.dll' could not be found.

Diese Nachrichten entsprechen dem hier gezeigten speziellen fünfteiligen Format. Die Reihenfolge dieser Teile ist wichtig und sollte nicht geändert werden.

Origin : Subcategory Category Code : Text

Beispiel:

c1 : Command line warning D4024 : unrecognized source file type 'test.xyz'

Origin: c1
Subcategory: Command line
Category: warning
Code: D4024
Text: unrecognized source file type 'test.zyz'

Details zu den einzelnen Komponenten dieses Formats:

  • Origin (erforderlich) Origin darf leer sein. Wenn vorhanden, ist Origin in der Regel ein Toolname, z. B. cl in einem der Beispiele. Auch ein Dateiname ist jedoch möglich, z. B. „Main.cs“ in einem anderen Beispiel. Wenn es sich um einen Dateinamen handelt, muss dieser absolut oder relativ sein, gefolgt von einer optionalen Zeilen- oder Spalteninformation in Klammern, die eines der folgenden Formate aufweist:

    (line) or (line-line) or (line-col) or (line,col-col) or (line,col,line,col)

    Zeilen und Spalten beginnen bei 1 in einer Datei. Das heißt: Der Anfang einer Datei ist 1, und die äußerste linke Spalte ist 1. Wenn Origin ein Toolname ist, darf er sich nicht basierend auf einem Gebietsschema ändern. Er muss also gebietsschemaneutral sein.

  • Subcategory (optional) Subcategory wird verwendet, um die Kategorie selbst weiter zu klassifizieren. Dieser Wert sollte nicht lokalisiert werden.

  • Category (erforderlich) Category muss entweder „error“ oder „warning“ lauten. Die Groß- und Kleinschreibung spielt keine Rolle. Genau wie Origin darf Category nicht lokalisiert werden.

  • Code (optional) Code ist ein anwendungsspezifischer Fehler- oder Warnungscode. Code darf nicht lokalisiert werden und keine Leerzeichen enthalten.

  • Text Benutzerfreundlicher Text, der den Fehler erklärt und lokalisiert werden muss, wenn mehrere Gebietsschemas bedient werden

Wenn MSBuild Befehlszeilentools (z. B. csc.exe oder vbc.exe) aufruft, wird die Ausgabe, die vom Tool ausgegeben wird, in den Standardstreams für Ausgaben und Fehler angezeigt. Alle Zeilen, die dem soeben beschriebenen Fehlerformat entsprechen, werden besonders behandelt. Das heißt, dass Zeilen, die als Fehler oder Warnungen erkannt werden, in Buildfehler und -warnungen umgewandelt werden. Die Vorteile daran erkennen Sie am besten, wenn Sie ein Entwicklungstool wie Visual Studio oder Visual Studio Code verwenden. Da MSBuild diese Nachrichten besonders behandelt, werden sie als vorrangige Warnungen und Fehler in der Visual Studio-Taskliste protokolliert. Wenn Origin Zeilen- und Spalteninformationen angibt, gelangen Sie durch einen Doppelklick zur Fehlerquelle in der entsprechenden Datei.

Zugehöriger Inhalt