Mendiagnosis kegagalan tugas MSBuild

Artikel
03/05/2024

MSB6006 dipancarkan ketika ToolTaskkelas –turunan menjalankan proses alat yang mengembalikan kode keluar bukan nol jika tugas tidak mencatat kesalahan yang lebih spesifik.

Mengidentifikasi tugas yang gagal

Saat Anda mengalami kesalahan tugas, langkah pertama adalah mengidentifikasi tugas yang gagal.

Teks kesalahan menentukan nama alat (baik nama yang mudah diingat yang disediakan oleh implementasi tugas ToolName atau nama yang dapat dieksekusi) dan kode keluar numerik. Misalnya, dalam error MSB6006: "custom tool" exited with code 1. nama alat adalah custom tool dan kode keluarnya adalah 1.

Untuk menemukan tugas MSBuild yang gagal:

Dalam build baris perintah: Jika build dikonfigurasi untuk menyertakan ringkasan (default), ringkasannya terlihat seperti ini:
```
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.
```
Hasil ini menunjukkan bahwa kesalahan terjadi dalam tugas yang ditentukan pada baris 19 file S:\MSB6006_demo\MSB6006_demo.csproj, dalam target bernama InvokeToolTask, dalam proyek S:\MSB6006_demo\MSB6006_demo.csproj.
Di UI Visual Studio: Informasi yang sama tersedia di daftar kesalahan Visual Studio di kolom Project, File, dan Line.

Temukan informasi kegagalan lainnya

Kesalahan MSB6006 dipancarkan ketika tugas tidak mencatat kesalahan tertentu. Kegagalan untuk mencatat kesalahan sering terjadi karena tugas tidak dikonfigurasi untuk memahami format kesalahan yang dipancarkan oleh alat yang dipanggilnya.

Alat yang bereaksi baik umumnya memancarkan beberapa informasi kontekstual atau kesalahan ke output standar atau aliran kesalahan mereka, dan tugas menangkap dan mencatat informasi ini secara default. Lihat entri log sebelum terjadi kesalahan untuk informasi tambahan. Menjalankan ulang build dengan tingkat log yang lebih tinggi mungkin diperlukan untuk mempertahankan informasi ini. Mudah-mudahan, konteks atau kesalahan tambahan yang diidentifikasi dalam pengelogan mengungkapkan akar penyebab masalah. Jika tidak, Anda mungkin harus mempersempit potensi penyebabnya dengan memeriksa properti dan item yang merupakan input ke tugas yang gagal.

Catatan

MSBuild mengenali format output diagnostik tertentu. Detail format ini didokumentasikan dalam format MSBuild dan Visual Studio untuk pesan diagnostik.

Men-debug tugas

Saat men-debug tugas MSBuild, berikut adalah beberapa tips umum.

Persempit cakupan kasus repro sebanyak mungkin (misalnya, dengan mengatur /p:BuildProjectReferences=false dan memulai MSBuild dengan satu proyek tertentu atau satu target tertentu) agar memiliki lebih sedikit kode untuk dikerjakan.
Gunakan opsi /m:1 baris perintah MSBuild untuk memiliki satu proses MSBuild untuk men-debug.
Atur variabel MSBUILDDEBUGONSTART lingkungan ke 1 untuk mendapatkan debugger yang dilampirkan ke MSBuild saat diluncurkan.
Atur titik henti pada Execute metode tugas untuk dilalui.

Men-debug tugas kustom

Jika Anda menulis kode untuk tugas kustom, Anda dapat mempermudah debug dengan menambahkan panggilan untuk memanggil debugger dalam metode tugas Execute . Anda dapat memagari kode tersebut dengan pemeriksaan variabel lingkungan, sehingga ketika pengguna mengatur variabel lingkungan tersebut, maka tugas berhenti dan memberi pengguna kesempatan untuk men-debug. Anda dapat menggunakan System.Diagnostics.Debugger.Launch atau System.Diagnostics.Debugger.Break untuk meluncurkan atau menghentikan debugger.

Anda harus yakin untuk menambahkan pengelogan sebanyak mungkin dalam tugas kustom untuk mempermudah tugas bagi pengguna untuk men-debugnya. Ini penting ketika Anda akhirnya mengidentifikasi akar kasus kegagalan; tambahkan kode pengelogan yang cukup untuk mendeteksi dan melaporkan mode kegagalan tersebut di masa mendatang.

Pertimbangkan untuk menyiapkan lingkungan pengujian untuk tugas menggunakan xUnit. Lihat Unit pengujian C# di .NET Core menggunakan pengujian dotnet dan xUnit. Anda dapat mengonfigurasi pengujian xUnit untuk menggunakan MSBuild API untuk memanggil MSBuild secara terprogram dengan file proyek tiruan yang mencakup properti, item, dan target yang Anda butuhkan untuk menjalankan tugas yang dimaksud. Dalam beberapa kasus, mungkin masuk akal untuk membuat mesin build tiruan. Anda dapat melihat contoh di Unit menguji tugas MSBuild kustom dengan Visual Studio.

Dalam proyek .NET SDK, Anda juga dapat memodifikasi peluncuran Pengaturan.json untuk menambahkan profil Debugging khusus yang berjalan MSBuild.exe dengan argumen baris perintah dan variabel lingkungan yang disebutkan sebelumnya dalam artikel ini.

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

Jika Anda ingin diminta untuk melampirkan debugger Anda sendiri saat runtime, atur variabel MSBUILDDEBUGONSTART lingkungan ke 2. Ini dapat membantu saat Anda menggunakan debugger yang berbeda, seperti di macOS saat Visual Studio tidak tersedia.

Bagikan melalui