Diagnostiquez les échecs de tâches MSBuild

MSB6006 est émis lorsqu’une tâche MSBuild, une ToolTaskclasse dérivée de MSBuild, exécute un processus d’outil qui retourne un code de sortie différent de zéro si la tâche n’a pas journalisée d’erreur plus spécifique.

Identifier la tâche défaillante

Lorsque vous rencontrez une erreur de tâche, la première étape consiste à identifier la tâche qui échoue.

Le texte de l’erreur spécifie le nom de l’outil (soit un nom convivial fourni par l’implémentation de ToolName la tâche, soit le nom de l’exécutable) et le code de sortie numérique. Par exemple, dans error MSB6006: "custom tool" exited with code 1. le nom de l'outil est custom tool et le code de sortie est 1.

Pour rechercher la tâche MSBuild ayant échoué :

• Dans les builds de ligne de commande : si la build est configurée pour inclure un résumé (la valeur par défaut), le résumé ressemble à ceci :

  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.
  

  Ce résultat indique que l’erreur s’est produite dans une tâche définie à la ligne 19 du fichier S:\MSB6006_demo\MSB6006_demo.csproj, dans une cible nommée InvokeToolTask, dans le projet S:\MSB6006_demo\MSB6006_demo.csproj.

• Dans l’interface utilisateur de Visual Studio : les mêmes informations sont disponibles dans la liste d’erreurs Visual Studio dans les colonnes Project, Fileet Line.

Trouver plus d’informations sur l’échec

Erreur MSB6006 est émise lorsque la tâche n’a pas journalisée une erreur spécifique. L’échec de journalisation d’une erreur est souvent dû au fait que la tâche n’est pas configurée pour comprendre le format d’erreur émis par l’outil qu’il appelle.

Les outils bien conçus émettent généralement des informations contextuelles ou d’erreur dans leur flux de sortie ou d’erreur standard, et les tâches capturent et enregistrent ces informations par défaut. Recherchez des informations supplémentaires dans les entrées du journal avant que l’erreur ne se soit produite. La réexécution de la compilation avec un niveau de journalisation supérieur peut être nécessaire pour conserver ces informations. Espérons que le contexte ou les erreurs supplémentaires identifiés dans la journalisation révèlent la cause racine du problème. Si ce n’est pas le cas, vous devrez peut-être limiter les causes potentielles en examinant les propriétés et les éléments qui sont des entrées dans la tâche défaillante.

Déboguer une tâche

Lorsque vous déboguez des tâches MSBuild, voici quelques conseils généraux.

• Limitez la portée du cas de reproduction autant que possible (par exemple, en définissant /p:BuildProjectReferences=false et en commençant MSBuild avec un projet spécifique ou une cible spécifique) pour avoir moins de code à utiliser.
• Utilisez l’option /m:1 de ligne de commande MSBuild pour avoir un seul processus MSBuild pour déboguer.
• Définissez la variable MSBUILDDEBUGONSTART d’environnement sur 1 pour obtenir un débogueur attaché à MSBuild au lancement.
• Placez un point d'arrêt sur la méthode Execute de la tâche à parcourir.

Déboguer une tâche personnalisée

Si vous écrivez du code pour une tâche personnalisée, vous pouvez faciliter le débogage en ajoutant un appel pour appeler le débogueur dans la méthode de Execute la tâche. Vous pouvez clôturer ce code avec une vérification de variable d’environnement afin que lorsqu’un utilisateur définit cette variable d’environnement, la tâche s’arrête et donne à l’utilisateur la possibilité de déboguer. Vous pouvez utiliser System.Diagnostics.Debugger.Launch ou System.Diagnostics.Debugger.Break pour lancer ou arrêter le débogueur.

Vous devez vous assurer d'ajouter autant de journalisation que possible dans une tâche personnalisée afin de faciliter le débogage de la tâche par les utilisateurs. Cela est important lorsque vous identifiez enfin le cas racine d’une défaillance ; ajoutez suffisamment de code de journalisation pour détecter et signaler ce mode d’échec à l’avenir.

Envisagez de configurer un environnement de test pour une tâche à l’aide de xUnit. Consultez Tests unitaires C# dans .NET Core à l’aide de dotnet test et xUnit. Vous pouvez configurer le test xUnit pour utiliser l’API MSBuild pour appeler MSBuild par programme avec un fichier projet fictif qui inclut les propriétés, les éléments et les cibles dont vous avez besoin pour exécuter la tâche en question. Dans certains cas, il peut être judicieux de créer un moteur de build fictif. Vous pouvez voir un exemple lors du test unitaire d’une tâche MSBuild personnalisée avec Visual Studio.

Dans les projets du Kit de développement logiciel (SDK) .NET, vous pouvez également modifier launchSettings.json pour ajouter un profil de débogage spécial qui s’exécute MSBuild.exe avec les arguments de ligne de commande et les variables d’environnement mentionnés précédemment dans cet article.

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

Si vous souhaitez être invité à attacher votre propre débogueur au moment de l’exécution, définissez la variable MSBUILDDEBUGONSTART d’environnement sur 2. Cela peut être utile lorsque vous utilisez un autre débogueur, par exemple sur macOS lorsque Visual Studio n’est pas disponible.