Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
MSB6006 é emitido quando uma tarefa do MSBuild, uma ToolTaskclasse derivada, executa um processo de ferramenta que retorna um código de saída diferente de zero se a tarefa não registra um erro mais específico.
Identificar a tarefa falha
Quando você encontra um erro de tarefa, a primeira etapa é identificar a tarefa que está falhando.
O texto do erro especifica o nome da ferramenta (um nome amigável fornecido pela implementação ToolName da tarefa ou o nome do executável) e o código de saída numérico. Por exemplo, no error MSB6006: "custom tool" exited with code 1. nome da ferramenta está custom tool e o código de saída é 1.
Para localizar a tarefa de MSBuild com falha:
Nos builds de linha de comando: se o build estiver configurado para incluir um resumo (o padrão), o resumo terá esta aparência:
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.Esse resultado indica que o erro ocorreu em uma tarefa definida na linha 19 do arquivo
S:\MSB6006_demo\MSB6006_demo.csproj, em um destino chamadoInvokeToolTask, no projetoS:\MSB6006_demo\MSB6006_demo.csproj.Na interface do usuário do Visual Studio: as mesmas informações estão disponíveis na lista de erros do Visual Studio nas colunas
ProjectFileeLine.
Encontrar mais informações de falha
O erro MSB6006 é emitido quando a tarefa não registra um erro específico. A falha ao registrar um erro geralmente ocorre porque a tarefa não está configurada para entender o formato de erro emitido pela ferramenta que ele chama.
As ferramentas bem comportadas geralmente emitem algumas informações contextuais ou de erro para a saída padrão ou o fluxo de erros, e as tarefas capturam e registram essas informações por padrão. Examine as entradas de log antes do erro ocorrer para obter informações adicionais. Executar novamente o build com um nível de log mais alto pode ser necessário para preservar essas informações. Espera-se que os erros ou o contexto adicional identificados no log revelem a causa raiz do problema. Caso contrário, talvez seja necessário restringir as possíveis causas examinando as propriedades e os itens que são entradas para a tarefa com falha.
Observação
O MSBuild reconhece um formato de saída de diagnóstico específico. Os detalhes desse formato são documentados no formato MSBuild e Visual Studio para mensagens de diagnóstico.
Depurar uma tarefa
Ao depurar tarefas do MSBuild, aqui estão algumas dicas gerais.
- Restringir o escopo do caso de reprodução ao máximo (por exemplo, configurando
/p:BuildProjectReferences=falsee iniciando o MSBuild com um projeto específico ou um alvo específico) para ter menos código com o qual trabalhar. - Use a opção
/m:1de linha de comando do MSBuild para ter um único processo do MSBuild para depurar. - Defina a variável
MSBUILDDEBUGONSTARTde ambiente como 1 para obter um depurador anexado ao MSBuild no início. - Defina um ponto de interrupção no método
Executeda tarefa a ser executada.
Depurar uma tarefa personalizada
Se você estiver escrevendo código para uma tarefa personalizada, poderá facilitar a depuração adicionando uma chamada para invocar o depurador no método da Execute tarefa. Você pode proteger esse código com uma checagem da variável de ambiente, para que, quando o usuário define a variável de ambiente, a tarefa pare e dê ao usuário a oportunidade de depurar. Você pode usar System.Diagnostics.Debugger.Launch ou System.Diagnostics.Debugger.Break para iniciar ou interromper o depurador.
Adicione o máximo de logs possível em uma tarefa personalizada para tornar a tarefa mais fácil para os usuários depurá-la. Isso é importante quando você finalmente identifica o caso raiz de uma falha; adicione código de log suficiente para detectar e relatar esse modo de falha no futuro.
Considere configurar um ambiente de teste para uma tarefa usando xUnit. Consulte Teste de unidade de C# no .NET Core usando dotnet test e xUnit. Você pode configurar o teste xUnit para usar a API do MSBuild para invocar o MSBuild programaticamente com um arquivo de projeto fictício que inclui as propriedades, os itens e os destinos necessários para executar a tarefa em questão. Em alguns casos, pode fazer sentido criar um mecanismo de build simulado. Você pode ver um exemplo na Unidade testar uma tarefa personalizada do MSBuild com o Visual Studio.
Em projetos do SDK do .NET, você também pode modificar launchSettings.json para adicionar um perfil de Depuração especial que executa MSBuild.exe com os argumentos de linha de comando e variáveis de ambiente mencionados anteriormente neste artigo.
"profiles": {
"Debug Build": {
"commandName": "Executable",
"executablePath": "$(MSBuildBinPath)\\MSBuild.exe",
"commandLineArgs": "/p:Configuration=$(Configuration) $(ProjectFileName) /m:1",
"workingDirectory": "$(ProjectDir)"
}
}
Se você quiser ser solicitado a anexar seu próprio depurador em tempo de execução, defina a variável de ambiente MSBUILDDEBUGONSTART como 2. Isso pode ser útil quando você estiver usando um depurador diferente, como no macOS, quando o Visual Studio não estiver disponível.