Diagnostisera MSBuild-uppgiftsfel

MSB6006 genereras när en MSBuild-uppgift, en ToolTask-härledd klass, kör en verktygsprocess som returnerar en icke-nollavslutskod om aktiviteten inte loggade ett mer specifikt fel.

Identifiera den misslyckade uppgiften

När du stöter på ett aktivitetsfel är det första steget att identifiera den uppgift som misslyckas.

Texten i felet specificerar verktygsnamnet (antingen ett beskrivande namn som tillhandahålls av uppgiftens implementering av ToolName eller namnet på den körbara filen) och den numeriska avslutningskoden. I error MSB6006: "custom tool" exited with code 1. är verktygets namn custom tool och slutkoden är 1.

Så här hittar du den misslyckade MSBuild-uppgiften:

  • I kommandoradsversionerna: Om bygget är konfigurerat att innehålla en sammanfattning (standard) ser sammanfattningen ut så här:

    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.

    Det här resultatet anger att felet inträffade i en aktivitet som definierats på rad 19 i filen S:\MSB6006_demo\MSB6006_demo.csproj, i ett mål med namnet InvokeToolTask, i projektet S:\MSB6006_demo\MSB6006_demo.csproj.

  • I Visual Studio-användargränssnittet: Samma information är tillgänglig i Visual Studio-fellistan i kolumnerna Project, Fileoch Line.

Hitta mer information om fel

Fel MSB6006 genereras när aktiviteten inte loggade ett specifikt fel. Det går inte att logga ett fel beror ofta på att uppgiften inte är konfigurerad för att förstå felformatet som genereras av verktyget som anropas.

Välbetedde verktyg genererar vanligtvis viss kontextuell information eller felinformation till sin standardutdata- eller felström, och processer samlar in och loggar denna information som standard. Titta i loggposterna innan felet uppstod för ytterligare information. Det kan krävas en ny körning av bygget med en högre loggnivå för att bevara den här informationen. Förhoppningsvis visar ytterligare kontext eller fel som identifierats i loggningen den bakomliggande orsaken till problemet. Annars kan du behöva begränsa de potentiella orsakerna genom att undersöka de egenskaper och objekt som är indata för den misslyckade aktiviteten.

Anmärkning

MSBuild identifierar ett specifikt diagnostikutdataformat. Information om det här formatet dokumenteras i MSBuild- och Visual Studio-format för diagnostikmeddelanden.

Felsöka en uppgift

Här följer några allmänna tips när du felsöker MSBuild-uppgifter.

  • Begränsa omfånget för repro-ärendet så mycket som möjligt (till exempel genom att ange /p:BuildProjectReferences=false och starta MSBuild med ett specifikt projekt eller ett specifikt mål) att ha mindre kod att arbeta med.
  • Använd kommandoradsalternativet /m:1 MSBuild för att ha en enda MSBuild-process att felsöka.
  • Ange miljövariabeln MSBUILDDEBUGONSTART till 1 för att få ett felsökningsprogram kopplat till MSBuild vid start.
  • Ange en brytpunkt i Execute metoden för uppgiften som du vill gå igenom.

Felsöka en anpassad uppgift

Om du skriver kod för en anpassad uppgift kan du göra det enklare att felsöka genom att lägga till ett anrop för att anropa felsökningsprogrammet i aktivitetens Execute metod. Du kan avgränsa koden med en miljövariabelkontroll, så att när en användare anger den miljövariabeln stoppas uppgiften och ger användaren möjlighet att felsöka. Du kan använda System.Diagnostics.Debugger.Launch eller System.Diagnostics.Debugger.Break för att starta eller bryta i felsökningsprogrammet.

Du bör se till att lägga till så mycket loggning som möjligt i en anpassad uppgift för att göra uppgiften enklare för användare att felsöka den. Detta är viktigt när du slutligen identifierar rotfallet för ett fel. lägg till tillräckligt med loggningskod för att identifiera och rapportera felläget i framtiden.

Överväg att konfigurera en testmiljö för en uppgift med hjälp av xUnit. Se Enhetstestning av C# i .NET Core med dotnet-test och xUnit. Du kan konfigurera xUnit-testet för att använda MSBuild-API:et för att anropa MSBuild programmatiskt med en modellprojektfil som innehåller de egenskaper, objekt och mål som du behöver för att köra uppgiften i fråga. I vissa fall kan det vara klokt att skapa en modellversionsmotor. Du kan se ett exempel i Unit test a custom MSBuild task with Visual Studio (Enhetstesta en anpassad MSBuild-uppgift med Visual Studio).

I .NET SDK-projekt kan du också ändra launchSettings.json för att lägga till en särskild felsökningsprofil som kör MSBuild.exe med kommandoradsargument och miljövariabler som nämns tidigare i den här artikeln.

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

Om du vill uppmanas att bifoga ett eget felsökningsprogram vid körning anger du miljövariabeln MSBUILDDEBUGONSTART till 2. Detta kan vara användbart när du använder ett annat felsökningsprogram, till exempel på macOS när Visual Studio inte är tillgängligt.

  • Last updated on