Compartir a través de

Diagnóstico de errores de tareas de MSBuild

MSB6006 se genera cuando una tarea de MSBuild, una ToolTaskclase derivada, ejecuta un proceso de herramienta que devuelve un código de salida distinto de cero si la tarea no registra un error más específico.

Identifica la tarea fallida

Cuando se produce un error de tarea, el primer paso es identificar la tarea que está fallando.

El texto del error especifica el nombre de la herramienta (un nombre descriptivo proporcionado por la implementación de la tarea o ToolName el nombre del ejecutable) y el código de salida numérico. Por ejemplo, en error MSB6006: "custom tool" exited with code 1. el nombre de la herramienta es custom tool y el código de salida es 1.

Para buscar la tarea de MSBuild con errores:

  • En las compilaciones de la línea de comandos: si la compilación está configurada para incluir un resumen (el valor predeterminado), el resumen tiene el siguiente aspecto:

    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.

    Este resultado indica que el error se produjo en una tarea definida en la línea 19 del archivo S:\MSB6006_demo\MSB6006_demo.csproj, en un destino denominado InvokeToolTask, en el proyecto S:\MSB6006_demo\MSB6006_demo.csproj.

  • En la interfaz de usuario de Visual Studio: la misma información está disponible en la lista de errores de Visual Studio en las columnas Project, Filey Line.

Búsqueda de más información sobre errores

El error MSB6006 se genera cuando la tarea no registra un error específico. La incapacidad de registrar un error suele ser porque la tarea no está configurada para entender el formato de error emitido por la herramienta que invoca.

Por lo general, las herramientas bien comportadas emiten información contextual o de error a su flujo de salida estándar o flujo de errores estándar, y las tareas capturan y registran esta información de forma predeterminada. Busque en las entradas de registro antes de que se produzca el error para obtener información adicional. Es posible que sea necesario volver a ejecutar la compilación con un nivel de registro superior para conservar esta información. Esperamos que el contexto adicional o los errores identificados en el registro muestren la causa principal del problema. Si no es así, puede que deba examinar las propiedades y los elementos que son entradas a la tarea con error para delimitar las causas posibles.

Nota:

MSBuild reconoce un formato de salida de diagnóstico específico. Los detalles de este formato se documentan en el formato MSBuild y Visual Studio para los mensajes de diagnóstico.

Depurar una tarea

Al depurar tareas de MSBuild, estas son algunas sugerencias generales.

  • Restrinja el ámbito del caso de reproducción tanto como sea posible (por ejemplo, estableciendo /p:BuildProjectReferences=false e inicia MSBuild con un proyecto específico o un destino específico) para tener menos código con el que trabajar.
  • Use la opción /m:1 de línea de comandos de MSBuild para tener un único proceso de MSBuild para depurar.
  • Establezca la variable de entorno MSBUILDDEBUGONSTART en 1 para adjuntar un depurador a MSBuild en el inicio.
  • Fije un punto de interrupción en el método Execute de la tarea para que vaya paso a paso.

Depurar una tarea personalizada

Si estás escribiendo código para una tarea personalizada, puedes facilitar la depuración agregando una llamada para invocar al depurador en el método de la tarea Execute. Puede cercar ese código con una variable de entorno, de modo que, cuando el usuario use esa variable de entorno, la tarea se detendrá y dará al usuario la oportunidad de realizar la depuración. Puede usar System.Diagnostics.Debugger.Launch o System.Diagnostics.Debugger.Break para iniciar o pausar la ejecución en el depurador.

Debe asegurarse de agregar tantos registros como sea posible en una tarea personalizada para que a los usuarios les resulta más fácil depurarla. Esto es importante cuando finalmente se identifica el caso raíz de un error; agregue suficiente código de registro para detectar y notificar ese modo de error en el futuro.

Considere la posibilidad de configurar un entorno de prueba para una tarea mediante xUnit. Consulte Pruebas unitarias de C# en .NET Core con dotnet test y xUnit. Puede configurar la prueba de xUnit para usar la API de MSBuild para invocar MSBuild mediante programación con un archivo de proyecto ficticio que incluya las propiedades, los elementos y los destinos que necesita para ejecutar la tarea en cuestión. En algunos casos, podría tener sentido crear un motor de compilación simulado. Puede ver un ejemplo en Prueba unitaria de una tarea personalizada de MSBuild con Visual Studio.

En los proyectos del SDK de .NET, también puede modificar launchSettings.json para agregar un perfil de depuración especial que ejecute MSBuild.exe con los argumentos de línea de comandos y las variables de entorno mencionadas anteriormente en este artículo.

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

Si desea que se le pida que adjunte su propio depurador en tiempo de ejecución, configure la variable de entorno MSBUILDDEBUGONSTART en 2. Esto puede resultar útil cuando se usa un depurador diferente, como en macOS cuando Visual Studio no está disponible.

  • Last updated on