次の方法で共有


MSBuild タスクの失敗を診断する

MSB6006 は、 ToolTask派生クラスである MSBuild タスクが、タスクがより具体的なエラーをログに記録しなかった場合に 0 以外の終了コードを返すツール プロセスを実行するときに生成されます。

失敗したタスクを特定する

タスク エラーが発生した場合、最初の手順は、失敗しているタスクを特定することです。

エラーのテキストは、ツール名 (タスクの 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.csprojInvokeToolTask という名前のターゲットで、ファイル S:\MSB6006_demo\MSB6006_demo.csprojの 19 行目に定義されたタスクでエラーが発生したことを示します。

  • Visual Studio UI の場合: 同じ情報が、 ProjectFileLineの列にある Visual Studio のエラー一覧で確認できます。

エラー情報の詳細を確認する

エラー MSB6006は、タスクが特定のエラーをログに記録しなかった場合に生成されます。 多くの場合、エラーのログ記録に失敗するのは、タスクが呼び出すツールによって出力されるエラー形式を理解するように構成されていないためです。

通常、適切に動作するツールは、コンテキスト情報またはエラー情報を標準の出力またはエラー ストリームに出力し、タスクはこの情報を既定でキャプチャしてログに記録します。 エラーが発生する前に、ログ エントリで追加情報を確認します。 この情報を保持するには、より高いログ レベルでビルドを再実行する必要がある場合があります。 できれば、ログ記録で特定された追加のコンテキストまたはエラーによって、問題の根本原因が明らかになります。 そうでない場合は、失敗したタスクへの入力であるプロパティと項目を調べることで、潜在的な原因を絞り込む必要があります。

MSBuild は、特定の診断出力形式を認識します。 この形式の詳細については、 MSBuild と Visual Studio の診断メッセージの形式に関するページを参照してください。

タスクをデバッグする

MSBuild タスクをデバッグする場合の一般的なヒントを次に示します。

  • (たとえば、 /p:BuildProjectReferences=false を設定し、1 つの特定のプロジェクトまたは 1 つの特定のターゲットで MSBuild を開始するなど) 再現ケースのスコープを絞り込んで、操作するコードを減らします。
  • MSBuild コマンド ライン オプション /m:1 使用して、デバッグする単一の MSBuild プロセスを作成します。
  • 起動時に MSBuild にデバッガーをアタッチするには、環境変数 MSBUILDDEBUGONSTART を 1 に設定します。
  • タスクをステップスルーするために、Execute メソッドにブレークポイントを設定します。

カスタム タスクをデバッグする

カスタム タスクのコードを記述する場合は、タスクの Execute メソッドでデバッガーを呼び出す呼び出しを追加することでデバッグを容易にすることができます。 ユーザーがその環境変数を設定したときにタスクが停止し、ユーザーにデバッグの機会を与えるように、環境変数チェックでそのコードをフェンスすることができます。 System.Diagnostics.Debugger.Launch または System.Diagnostics.Debugger.Break を使用して、デバッガーを起動または中断できます。

ユーザーがタスクをデバッグしやすくするために、カスタム タスクにできるだけ多くのログ記録を追加する必要があります。 これは、障害のルート ケースを最終的に特定するときに重要です。今後、そのエラー モードを検出して報告するのに十分なログ コードを追加します。

xUnit を使用してタスクのテスト環境を設定することを検討してください。 dotnet テストと xUnit を使用した .NET Core での単体テスト C# に関する説明を参照してください。 問題のタスクを実行するために必要なプロパティ、項目、ターゲットを含むモック プロジェクト ファイルを使用して、MSBuild API を使用して MSBuild をプログラムで呼び出すように xUnit テストを構成できます。 場合によっては、モック ビルド エンジンを作成するのが理にかなっている場合があります。 Visual Studio でのカスタム MSBuild タスクの単体テストの例を確認できます。

.NET SDK プロジェクトでは、 launchSettings.json を変更して、この記事で前述したコマンドライン引数と環境変数を 使用してMSBuild.exe 実行する特別なデバッグ プロファイルを追加することもできます。

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

実行時に独自のデバッガーをアタッチするように求めるメッセージが表示される場合は、環境変数 MSBUILDDEBUGONSTART2 に設定します。 これは、Visual Studio が使用できない macOS など、別のデバッガーを使用している場合に役立ちます。