MsBuild-taakfouten diagnosticeren

MSB6006 wordt verzonden wanneer een MSBuild-taak, een ToolTask–afgeleide klasse, een hulpprogrammaproces uitvoert dat een niet-nul-afsluitcode retourneert als de taak geen specifiekere fout heeft vastgelegd.

De mislukte taak identificeren

Wanneer u een taakfout tegenkomt, is de eerste stap het identificeren van de taak die mislukt.

De tekst van de fout specificeert de naam van de tool (hetzij een beschrijvende naam gegeven door de implementatie van de taak in ToolName, of de naam van het uitvoerbare bestand) en de numerieke exit code. Bijvoorbeeld, in error MSB6006: "custom tool" exited with code 1. is de naam van het hulpprogramma custom tool en de afsluitcode is 1.

De mislukte MSBuild-taak vinden:

• In de opdrachtregelbuilds: Als de build is geconfigureerd voor het opnemen van een samenvatting (de standaardinstelling), ziet de samenvatting er als volgt uit:

  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.
  

  Dit resultaat geeft aan dat de fout is opgetreden in een taak die is gedefinieerd op regel 19 van het bestand S:\MSB6006_demo\MSB6006_demo.csproj, in een doel met de naam InvokeToolTask, in het project S:\MSB6006_demo\MSB6006_demo.csproj.

• In de gebruikersinterface van Visual Studio: dezelfde informatie is beschikbaar in de lijst met Visual Studio-fouten in de kolommen Project, Fileen Line.

Meer informatie over fouten zoeken

Fout MSB6006 wordt verzonden wanneer de taak geen specifieke fout heeft vastgelegd. De fout bij het vastleggen van een fout komt vaak doordat de taak niet is geconfigureerd om inzicht te hebben in de foutindeling die wordt verzonden door het hulpprogramma dat wordt aangeroepen.

Goed gedragende hulpprogramma's verzenden over het algemeen contextuele of foutinformatie naar hun standaarduitvoer- of foutstroom, en taken leggen deze informatie standaard vast en registreren deze gegevens. Zoek in de logboekvermeldingen voordat de fout is opgetreden voor aanvullende informatie. Het opnieuw uitvoeren van de build met een hoger logboekniveau is mogelijk vereist om deze informatie te behouden. Hopelijk geven de aanvullende context of fouten in logboekregistratie de hoofdoorzaak van het probleem aan. Als dat niet het geval is, moet u mogelijk de mogelijke oorzaken beperken door de eigenschappen en items te onderzoeken die invoer zijn voor de mislukte taak.

Fouten opsporen in een taak

Bij het opsporen van fouten in MSBuild-taken volgen hier enkele algemene tips.

• Beperk het bereik van de reprocase zoveel mogelijk (bijvoorbeeld door MSBuild in te stellen /p:BuildProjectReferences=false en te starten met één specifiek project of één specifiek doel) om minder code te gebruiken om mee te werken.
• Gebruik de msBuild-opdrachtregeloptie /m:1 om één MSBuild-proces te hebben om fouten op te sporen.
• Stel de omgevingsvariabele MSBUILDDEBUGONSTART in op 1 om bij de lancering een foutopsporingsprogramma op te halen dat is gekoppeld aan MSBuild.
• Stel een onderbrekingspunt in bij de Execute methode van de taak die u wilt doorlopen.

Fouten opsporen in een aangepaste taak

Als u code schrijft voor een aangepaste taak, kunt u eenvoudiger fouten opsporen door een aanroep toe te voegen om het foutopsporingsprogramma in de methode van Execute de taak aan te roepen. U kunt die code afschermen met een controle van een omgevingsvariabele, zodat wanneer een gebruiker die omgevingsvariabele instelt, de taak stopt en de gebruiker de mogelijkheid biedt om fouten op te sporen. U kunt System.Diagnostics.Debugger.Launch of System.Diagnostics.Debugger.Break gebruiken om het foutopsporingsprogramma te starten of te verbreken.

Zorg ervoor dat u zoveel mogelijk logboekregistratie toevoegt aan een aangepaste taak om de taak gemakkelijker te maken voor gebruikers om fouten op te sporen. Dit is belangrijk wanneer u eindelijk de hoofdcase van een fout identificeert; voeg voldoende logboekcode toe om die foutmodus in de toekomst te detecteren en te rapporteren.

U kunt een testomgeving instellen voor een taak met behulp van xUnit. Zie Eenheidstests C# in .NET Core met behulp van dotnet-test en xUnit. U kunt de xUnit-test configureren om de MSBuild-API te gebruiken om MSBuild programmatisch aan te roepen met een mockprojectbestand met de eigenschappen, items en doelen die u nodig hebt voor het uitvoeren van de betreffende taak. In sommige gevallen kan het zinvol zijn om een mock-build-engine te maken. U ziet een voorbeeld bij Unit test een aangepaste MSBuild-taak met Visual Studio.

In .NET SDK-projecten kunt u ook launchSettings.json wijzigen om een speciaal foutopsporingsprofiel toe te voegen dat MSBuild.exe uitvoert met de opdrachtregelargumenten en omgevingsvariabelen die eerder in dit artikel zijn genoemd.

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

Als u tijdens runtime wilt worden gevraagd uw eigen foutopsporingsprogramma te koppelen, stelt u de omgevingsvariabele MSBUILDDEBUGONSTART in op 2. Dit kan handig zijn wanneer u een ander foutopsporingsprogramma gebruikt, zoals in macOS wanneer Visual Studio niet beschikbaar is.