Diagnozowanie błędów zadań programu MSBuild

MSB6006 jest emitowany, gdy ToolTaskklasa pochodna uruchamia proces narzędzia, który zwraca kod zakończenia niezerowy, jeśli zadanie nie zarejestrowało bardziej szczegółowego błędu.

Identyfikowanie zadania zakończonego niepowodzeniem

W przypadku wystąpienia błędu zadania pierwszym krokiem jest zidentyfikowanie zadania, które kończy się niepowodzeniem.

Tekst błędu określa nazwę narzędzia (przyjazną nazwę podaną przez implementację ToolName zadania lub nazwę pliku wykonywalnego) oraz numeryczny kod zakończenia. Na przykład w error MSB6006: "custom tool" exited with code 1. nazwie narzędzia jest custom tool i kod zakończenia to 1.

Aby znaleźć zadanie MSBuild, które zakończyło się niepowodzeniem:

• W kompilacjach wiersza polecenia: jeśli kompilacja jest skonfigurowana do uwzględnienia podsumowania (wartość domyślna), podsumowanie wygląda następująco:

  Build FAILED.
  
  "S:\MSB6006_demo\MSB6006_demo.csproj" (default target) (1) ->
  (InvokeToolTask target) ->
    S:\MSB6006_demo\MSB6006_demo.csproj(19,5): error MSB6006: "custom tool" exited with code 1.
  

  Ten wynik wskazuje, że błąd wystąpił w zadaniu zdefiniowanym w wierszu 19 pliku S:\MSB6006_demo\MSB6006_demo.csproj, w obiekcie docelowym o nazwie InvokeToolTask, w projekcie S:\MSB6006_demo\MSB6006_demo.csproj.

• W interfejsie użytkownika programu Visual Studio: te same informacje są dostępne na liście błędów programu Visual Studio w kolumnach Project, Filei Line.

Znajdź więcej informacji o niepowodzeniu

Błąd MSB6006 jest emitowany, gdy zadanie nie zarejestrowało określonego błędu. Niepowodzenie rejestrowania błędu jest często spowodowane tym, że zadanie nie jest skonfigurowane do zrozumienia formatu błędu emitowanego przez narzędzie, które wywołuje.

Dobrze zachowywane narzędzia zwykle emitują pewne informacje kontekstowe lub informacje o błędach do standardowych danych wyjściowych lub strumienia błędów, a zadania domyślnie przechwytują i rejestrują te informacje. Poszukaj wpisów dziennika przed wystąpieniem błędu, aby uzyskać dodatkowe informacje. Ponowne uruchomienie kompilacji z wyższym poziomem dziennika może być wymagane, aby zachować te informacje. Mam nadzieję, że dodatkowy kontekst lub błędy zidentyfikowane w rejestrowaniu ujawniają główną przyczynę problemu. Jeśli nie, może być konieczne zawężenie potencjalnych przyczyn, sprawdzając właściwości i elementy, które są danymi wejściowymi zadania zakończonego niepowodzeniem.

Uwaga

Program MSBuild rozpoznaje określony format danych wyjściowych diagnostycznych. Szczegóły tego formatu są udokumentowane w formacie MSBuild i Visual Studio dla komunikatów diagnostycznych.

Debugowanie zadania

Podczas debugowania zadań programu MSBuild poniżej przedstawiono kilka ogólnych wskazówek.

• Zawęź zakres przypadku odtworzenia tak bardzo, jak to możliwe (na przykład przez ustawienie /p:BuildProjectReferences=false i uruchomienie programu MSBuild z jednym konkretnym projektem lub jednym konkretnym celem), aby mieć mniej kodu do pracy.
• Użyj opcji /m:1 wiersza polecenia MSBuild, aby debugować pojedynczy proces MSBuild.
• Ustaw zmienną środowiskową MSBUILDDEBUGONSTART na 1, aby uzyskać debuger dołączony do programu MSBuild podczas uruchamiania.
• Ustaw punkt przerwania w Execute metodzie zadania, aby przejść przez.

Debugowanie zadania niestandardowego

Jeśli piszesz kod dla zadania niestandardowego, możesz ułatwić debugowanie, dodając wywołanie w celu wywołania debugera w metodzie zadania Execute . Możesz ogrodzenia tego kodu za pomocą sprawdzania zmiennej środowiskowej, dzięki czemu gdy użytkownik ustawia taką zmienną środowiskową, zadanie zatrzymuje się i daje użytkownikowi możliwość debugowania. Aby uruchomić lub przerwać debuger, możesz użyć polecenia System.Diagnostics.Debugger.Break.

Pamiętaj, aby dodać jak najwięcej rejestrowania w niestandardowym zadaniu, aby ułatwić użytkownikom debugowanie. Jest to ważne, gdy w końcu zidentyfikujesz przypadek główny awarii; dodaj wystarczającą ilość kodu rejestrowania, aby wykryć i zgłosić ten tryb awarii w przyszłości.

Rozważ skonfigurowanie środowiska testowego dla zadania przy użyciu narzędzia xUnit. Zobacz Testowanie jednostkowe języka C# na platformie .NET Core przy użyciu testu dotnet i narzędzia xUnit. Test xUnit można skonfigurować tak, aby używał interfejsu API MSBuild do programowego wywoływania programu MSBuild za pomocą pozornego pliku projektu zawierającego właściwości, elementy i elementy docelowe potrzebne do uruchamiania danego zadania. W niektórych przypadkach warto utworzyć pozorny aparat kompilacji. Przykład można znaleźć w temacie Unit test a custom MSBuild task with Visual Studio (Testowanie jednostkowe niestandardowego zadania MSBuild w programie Visual Studio).

W projektach zestawu .NET SDK można również zmodyfikować uruchamianie Ustawienia.json aby dodać specjalny profil debugowania uruchamiany MSBuild.exe z argumentami wiersza polecenia i zmiennymi środowiskowymi wymienionymi wcześniej w tym artykule.

"profiles": {
  "Debug Build": {
    "commandName": "Executable",
    "executablePath": "$(MSBuildBinPath)\\MSBuild.exe",
    "commandLineArgs": "/p:Configuration=$(Configuration) $(ProjectFileName) /m:1",
    "workingDirectory": "$(ProjectDir)"
  }
}

Jeśli chcesz wyświetlić monit o dołączenie własnego debugera w czasie wykonywania, ustaw zmienną środowiskową MSBUILDDEBUGONSTART na 2. Może to być przydatne, gdy używasz innego debugera, takiego jak w systemie macOS, gdy program Visual Studio nie jest dostępny.