Diagnosticare gli errori delle attività di MSBuild

  • Articolo

MSB6006 viene generato quando una ToolTaskclasse derivata da –esegue un processo di strumento che restituisce un codice di uscita diverso da zero se l'attività non ha registrato un errore più specifico.

Identificare l'attività con errori

Quando si verifica un errore di attività, il primo passaggio consiste nell'identificare l'attività che ha esito negativo.

Il testo dell'errore specifica il nome dello strumento (un nome descrittivo fornito dall'implementazione dell'attività di ToolName o il nome dell'eseguibile) e il codice di uscita numerico. Ad esempio, nel error MSB6006: "custom tool" exited with code 1. nome dello strumento è custom tool e il codice di uscita è 1.

Per trovare l'attività MSBuild non riuscita:

  • Nelle compilazioni della riga di comando: se la compilazione è configurata per includere un riepilogo (impostazione predefinita), il riepilogo sarà simile al seguente:

    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.

    Questo risultato indica che l'errore si è verificato in un'attività definita nella riga 19 del file S:\MSB6006_demo\MSB6006_demo.csproj, in una destinazione denominata InvokeToolTask, nel progetto S:\MSB6006_demo\MSB6006_demo.csproj.

  • Nell'interfaccia utente di Visual Studio: le stesse informazioni sono disponibili nell'elenco degli errori di Visual Studio nelle colonne Project, Filee Line.

Altre informazioni sugli errori

L'errore MSB6006 viene generato quando l'attività non ha registrato un errore specifico. L'errore di registrazione di un errore è spesso dovuto al fatto che l'attività non è configurata per comprendere il formato di errore generato dallo strumento che chiama.

Gli strumenti ben comportati in genere generano alcune informazioni contestuali o di errore per l'output standard o il flusso di errori e le attività acquisiscono e registrano queste informazioni per impostazione predefinita. Cercare le voci di log prima che si sia verificato l'errore per altre informazioni. Per conservare queste informazioni, potrebbe essere necessario riesecure la compilazione con un livello di log superiore. Si spera che il contesto aggiuntivo o gli errori identificati nella registrazione rivelano la causa radice del problema. In caso contrario, potrebbe essere necessario limitare le possibili cause esaminando le proprietà e gli elementi che sono input per l'attività con errori.

Nota

MSBuild riconosce un formato di output di diagnostica specifico. I dettagli di questo formato sono documentati nel formato MSBuild e Visual Studio per i messaggi di diagnostica.

Eseguire il debug di un'attività

Durante il debug delle attività di MSBuild, ecco alcuni suggerimenti generali.

  • Restringere il più possibile l'ambito del caso di riproduzione, ad esempio impostando /p:BuildProjectReferences=false e avviando MSBuild con un progetto specifico o una destinazione specifica, in modo da avere meno codice da usare.
  • Usare l'opzione /m:1 della riga di comando MSBuild per avere un singolo processo MSBuild per eseguire il debug.
  • Impostare la variabile MSBUILDDEBUGONSTART di ambiente su 1 per ottenere un debugger collegato a MSBuild all'avvio.
  • Impostare un punto di interruzione nel Execute metodo dell'attività per eseguire un'istruzione dettagliata.

Eseguire il debug di un'attività personalizzata

Se si scrive codice per un'attività personalizzata, è possibile semplificare il debug aggiungendo una chiamata per richiamare il debugger nel metodo dell'attività Execute . È possibile evitare che il codice venga delimitato con un controllo di variabile di ambiente, in modo che quando un utente imposta tale variabile di ambiente, l'attività si arresta e offre all'utente la possibilità di eseguire il debug. È possibile usare System.Diagnostics.Debugger.Launch o System.Diagnostics.Debugger.Break per avviare o interrompere il debugger.

Assicurarsi di aggiungere il maggior numero possibile di registrazione in un'attività personalizzata per semplificare il debug dell'attività da parte degli utenti. Questo è importante quando si identifica infine il caso radice di un errore; aggiungere codice di registrazione sufficiente per rilevare e segnalare la modalità di errore in futuro.

Provare a configurare un ambiente di test per un'attività usando xUnit. Vedere Unit testing C# in .NET Core con dotnet test e xUnit. È possibile configurare il test xUnit per usare l'API MSBuild per richiamare MSBuild a livello di codice con un file di progetto fittizio che include le proprietà, gli elementi e le destinazioni necessarie per eseguire l'attività in questione. In alcuni casi, potrebbe essere opportuno creare un motore di compilazione fittizio. È possibile visualizzare un esempio in Unit test di un'attività MSBuild personalizzata con Visual Studio.

Nei progetti .NET SDK è anche possibile modificare l'avvio Impostazioni.json per aggiungere un profilo di debug speciale che esegue MSBuild.exe con gli argomenti della riga di comando e le variabili di ambiente menzionate in precedenza in questo articolo.

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

Se si desidera collegare il debugger in fase di esecuzione, impostare la variabile MSBUILDDEBUGONSTART di ambiente su 2. Ciò può essere utile quando si usa un debugger diverso, ad esempio in macOS quando Visual Studio non è disponibile.