MSBuild 작업 실패 진단
MSB6006
는 -derived 클래스가 태스크가 더 구체적인 오류를 기록하지 않은 경우 0이 아닌 종료 코드를 반환하는 도구 프로세스를 실행할 때 ToolTask내보내집니다.
실패한 작업 확인
작업 오류가 발생하면 첫 번째 단계는 실패한 작업을 식별하는 것입니다.
오류 텍스트는 도구 이름(작업의 ToolName 구현에서 제공하는 식별 이름 또는 실행 파일의 이름)과 숫자 종료 코드를 지정합니다. 예를 들어 error MSB6006: "custom tool" exited with code 1.
에서 도구 이름은 custom tool
이고 종료 코드는 1
입니다.
실패한 MSBuild 작업을 찾으려면
명령줄 빌드에서: 빌드가 요약(기본값)을 포함하도록 구성된 경우 요약은 다음과 같습니다.
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.
이 결과는 프로젝트
S:\MSB6006_demo\MSB6006_demo.csproj
에서InvokeToolTask
라는 대상의 파일S:\MSB6006_demo\MSB6006_demo.csproj
의 19번 줄에 정의된 작업에서 오류가 발생했음을 나타냅니다.Visual Studio UI:
Project
,File
및Line
열의 Visual Studio 오류 목록에서 동일한 정보를 사용할 수 있습니다.
추가 실패 정보 찾기
작업에서 특정 오류를 기록하지 않은 경우 오류 MSB6006 내보내집니다. 오류가 기록되지 않는 이유는 태스크가 호출하는 도구에서 내보낸 오류 형식을 이해하도록 구성되지 않았기 때문입니다.
정상적으로 작동하는 도구는 일반적으로 일부 문맥 또는 오류 정보를 표준 출력 또는 오류 스트림으로 내보내고 작업이 기본적으로 이 정보를 캡처하고 기록합니다. 추가 정보에 대해 오류가 발생하기 전에 로그 항목을 확인합니다. 이 정보를 유지하려면 더 높은 로그 수준으로 빌드를 다시 실행해야 할 수 있습니다. 로그에서 식별된 추가 컨텍스트나 오류는 문제의 근본 원인을 나타냅니다. 그렇지 않은 경우 실패한 작업에 입력된 속성 및 항목을 검사하여 잠재적인 원인의 범위를 좁혀야 합니다.
참고
MSBuild는 특정 진단 출력 형식을 인식합니다. 이 형식의 세부 정보는 진단 메시지에 대한 MSBuild 및 Visual Studio 형식에 설명되어 있습니다.
작업 디버그
MSBuild 작업을 디버깅할 때 몇 가지 일반적인 팁은 다음과 같습니다.
- 작업할 코드가 적도록 재현 사례의 범위를 최대한 좁히세요(예: 특정 프로젝트 또는 하나의 특정 대상으로 MSBuild를 설정
/p:BuildProjectReferences=false
및 시작). - MSBuild 명령줄 옵션을
/m:1
사용하여 디버그할 단일 MSBuild 프로세스를 만듭니다. - 시작 시 MSBuild에 연결된 디버거를 얻으려면 환경 변수
MSBUILDDEBUGONSTART
를 1로 설정합니다. - 단계별로 실행할 작업의 메서드에서
Execute
중단점을 설정합니다.
사용자 지정 작업 디버그
사용자 지정 작업에 대한 코드를 작성하는 경우 태스크 Execute
의 메서드에서 디버거를 호출하는 호출을 추가하여 디버그를 더 쉽게 만들 수 있습니다. 검사 환경 변수를 사용하여 해당 코드를 펜스할 수 있으므로 사용자가 해당 환경 변수를 설정할 때 작업이 중지되고 사용자에게 디버그할 수 있는 기회를 제공합니다. System.Diagnostics.Debugger.Launch 또는 System.Diagnostics.Debugger.Break를 사용하여 디버거를 시작하거나 중단할 수 있습니다.
사용자가 작업을 더 쉽게 디버그할 수 있도록 사용자 지정 태스크에 가능한 한 많은 로깅을 추가해야 합니다. 이는 마지막으로 실패의 근본 사례를 식별할 때 중요합니다. 로깅 코드를 추가하여 나중에 해당 실패 모드를 검색하고 보고할 수 있습니다.
xUnit을 사용하여 작업에 대한 테스트 환경을 설정하는 것이 좋습니다. dotnet test 및 xUnit을 사용하여 .NET Core의 단위 테스트 C#을 참조하세요. MSBuild API를 사용하여 해당 작업을 실행하는 데 필요한 속성, 항목 및 대상이 포함된 모의 프로젝트 파일을 사용하여 MSBuild를 프로그래밍 방식으로 호출하도록 xUnit 테스트를 구성할 수 있습니다. 경우에 따라 모의 빌드 엔진을 만드는 것이 합리적일 수 있습니다. Visual Studio를 사용하여 사용자 지정 MSBuild 작업을 단위 테스트에 대한 예제를 볼 수 있습니다.
.NET SDK 프로젝트에서는 시작설정.json 수정하여 이 문서의 앞부분에서 멘션 명령줄 인수 및 환경 변수를 사용하여 MSBuild.exe 실행하는 특수 디버깅 프로필을 추가할 수도 있습니다.
"profiles": {
"Debug Build": {
"commandName": "Executable",
"executablePath": "$(MSBuildBinPath)\\MSBuild.exe",
"commandLineArgs": "/p:Configuration=$(Configuration) $(ProjectFileName) /m:1",
"workingDirectory": "$(ProjectDir)"
}
}
런타임에 사용자 고유의 디버거를 연결하라는 메시지가 표시되려면 환경 변수 MSBUILDDEBUGONSTART
를 2
.로 설정합니다. 이는 Visual Studio를 사용할 수 없는 경우 macOS와 같이 다른 디버거를 사용하는 경우에 유용할 수 있습니다.