Udostępnij za pośrednictwem

Format MSBuild i Visual Studio dla komunikatów diagnostycznych

  • Artykuł

Po wykonaniu narzędzia, które wyprowadza jakiś tekst, program MSBuild sprawdza tekst pod kątem błędów i ostrzeżeń. Wiele narzędzi używa znanego formatu do raportowania tych komunikatów. Domyślnie program MSBuild sprawdza tekst i zgłasza błędy i/lub ostrzeżenia na podstawie danych wyjściowych. To zachowanie można rozszerzyć lub wyłączyć przy użyciu tych parametrów w Exec zadaniu: IgnoreStandardErrorWarningFormat, CustomErrorRegularExpressioni CustomWarningRegularExpression.

Uwaga

Jeśli zdecydujesz się użyć własnego wyrażenia regularnego do wykrywania błędów i ostrzeżeń, musisz wiedzieć, że program MSBuild przyjrzy się wynikowi po jednym wierszu naraz. Nawet jeśli niestandardowe wyrażenie regularne będzie pasowało do czegoś w wielu wierszach, nie będzie zachowywać się w ten sposób ze względu na sposób przetwarzania tekstu przez program MSBuild.

Przyjrzyj się następującym czterem komunikatom, które są poprawnie sformatowane i będą rozpoznawane przez program MSBuild i program Microsoft Visual Studio:

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.

Te komunikaty są zgodne ze specjalnym pięcioczęściowym formatem pokazanym tutaj. Kolejność tych części jest ważna i nie powinna się zmieniać.

Origin: Subcategory Category CodeText

Na przykład:

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'

Każdy z składników tego formatu jest opisany w następujący sposób:

  • Źródło (wymagane) źródło może być puste. Jeśli istnieje, źródło jest zwykle nazwą narzędzia, taką jak cl w jednym z przykładów. Ale może to być również nazwa pliku, taka jak "Main.cs", pokazana w innym przykładzie. Jeśli jest to nazwa pliku, musi być bezwzględną lub względną nazwą pliku, a następnie opcjonalną informacją o linii/kolumnie nawiasu w jednej z następujących formularzy:

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

    Wiersze i kolumny zaczynają się od 1 w pliku; oznacza to, że początek pliku to 1, a lewa kolumna to 1. Jeśli źródło jest nazwą narzędzia, nie może zmienić się na podstawie ustawień regionalnych; oznacza to, że musi być neutralne dla ustawień regionalnych.

  • Podkategoria (opcjonalnie) podkategoria służy do dalszego klasyfikowania kategorii. Nie należy jej lokalizować.

  • Kategoria (wymagana) musi mieć wartość "błąd" lub "ostrzeżenie". Sprawa nie ma znaczenia. Podobnie jak w przypadku źródła, kategoria nie może być zlokalizowana.

  • Kod (opcjonalnie) Kod identyfikuje kod błędu/ostrzeżenie specyficzne dla aplikacji. Kod nie może być zlokalizowany i nie może zawierać spacji.

  • Tekst przyjazny dla użytkownika, który wyjaśnia błąd i musi być zlokalizowany, jeśli obsługujesz wiele ustawień regionalnych.

Gdy program MSBuild wywołuje narzędzia wiersza polecenia (na przykład csc.exe lub vbc.exe), analizuje dane wyjściowe emitowane przez narzędzie do standardowych strumieni błędów i standardowych. Wszystkie wiersze pasujące do formatu błędu, który właśnie opisałem, będą traktowane specjalnie; oznacza to, że wiersze, które są rozpoznawane jako błędy lub ostrzeżenia, zostaną odpowiednio przekształcone w błędy kompilacji i ostrzeżenia. Aby zobaczyć rzeczywiste korzyści z tego problemu, musisz tworzyć z poziomu narzędzia programistycznego, takiego jak Visual Studio lub VS Code. Ponieważ program MSBuild traktuje te komunikaty specjalnie, są rejestrowane jako ostrzeżenia i błędy pierwszej klasy na liście zadań programu Visual Studio. Jeśli źródło określa informacje o wierszach/kolumnach, dwukrotne kliknięcie komunikatu spowoduje przejście do źródła błędu w pliku o przestępstwach.

Powiązana zawartość