Azure Pipelines：「Dotnet command failed with non-zero exit code on the following projects」
.NET Core のタスク（DotNetCoreCLI@2）は、パターンに合ったプロジェクト ファイルごとに dotnet を1回ずつ動かします。どれかが 0 以外のコードで終わると、タスクはそれをログに出して次のプロジェクトへ進み、最後に失敗したプロジェクトを全部このメッセージに並べます（タスクのソース）。つまりこのメッセージが言うのは、どのプロジェクトが失敗したかだけです。なぜ失敗したかは、その上にある dotnet 自身の出力にあります（このメッセージの Stack Overflow の質問は、合わせて32万回以上見られています）。
失敗しているステップがプルリクエストのビルド検証の一部なら、プルリクエストはそれを待っています：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、プルリクエストのブランチ ポリシーを状態つきで Rider に並べ、Pro なら直しを push したあとに、失敗したビルド ポリシーをもう一度動かせます。JetBrains Marketplace で入れる
どう見えるか
- 失敗した実行ごとに
##[error]Error: The process '/usr/bin/dotnet' failed with exit code 1（Windows では'C:\Program Files\dotnet\dotnet.exe'）、そのあとに##[error]Dotnet command failed with non-zero exit code on the following projects : /home/vsts/work/1/s/src/Web/Web.csproj。 - その前に、.NET 5 と NuGet 5.7 以前の相性についての警告が出ます。タスクは build・publish・run・test が失敗するたびにこれを出すので、原因になるのは、古い NuGet のタスクで復元したときだけです。
本当のエラーを見つける
- ステップのログを開き、メッセージより上で、
errorとコードのある行を探します。CSはコンパイラー、MSBは MSBuild、NETSDKは .NET SDK、NUは NuGet からです。直すのはたいてい最初の1つで、残りはそこから続いて出ていることがよくあります。 - ログが長ければ、実行のメニューからダウンロードして、そこで検索します。同じバージョンの SDK で、同じ
dotnetのコマンドを自分のマシンで動かすと、同じエラーが出ます。
ビルドするつもりのなかったプロジェクト
**/*.csprojのようなパターンは、リポジトリにあるすべてのプロジェクト ファイルに合います。ソリューションに入っていない古いもの、サンプル、壊れたプロジェクトもです。一番読まれている質問の採用された回答はまさにこれで、メッセージにあるプロジェクトはソリューションに入っていませんでした。projects:を、ソリューションのFabrikam.slnか、src/**/*.csprojのような狭いパターンにします。
エージェントの SDK
NETSDK1045: The current .NET SDK does not support targeting .NET 9.0は、エージェントの SDK がプロジェクトのTargetFrameworkより古いということです（NETSDK1045 についての Microsoft のページ）。- .NET Core のタスクの前に、
packageType: sdkとversion: 9.0.xを書いた- task: UseDotNet@2を足します。global.jsonがあるなら、代わりにuseGlobalJson: trueにすると、そのファイルが求める SDK をタスクが入れます（タスクのリファレンス）。
build・test・publish の中の復元
- build・test・publish は、まず自分でパッケージを復元します。認証の要るフィードでは、その前の復元のステップがうまくいっていても、この復元は失敗します。復元のステップが、使った資格情報を消しているからです。Microsoft の答えは、
argumentsに--no-restoreを足すことです（タスクのリファレンス）。test のコマンドはfeedRestoreとvstsFeedも無視するので、復元は別のステップでします。 - 復元での NuGet のエラーは、Unable to load the service index for source（NU1301）を見てください。
NU1101: Unable to find packageは、復元が使ったどのソースにもそのパッケージがないということです。フィードにないか、フィードのアップストリーム ソースがオフです。 --no-restoreにしたら、復元はあとのコマンドと合っていなければなりません。-r linux-x64をつけた publish が、それなしの復元のあとに動くと、assets ファイルにそのランタイムのターゲットがないというNETSDK1047で失敗します。復元にも同じ-rをつけます。
失敗したテスト
dotnet testはテストが1つでも失敗すると 1 で終わり、タスクはそのテスト プロジェクトをこのメッセージに出します。publishTestResultsが既定のオンなら、タスクは失敗する前にテストの結果を出すので、実行の Tests のタブで、どのテストがなぜ失敗したかが見られます。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエスト
Azure DevOps Pull Requests は、JetBrains IDE 2024.1 以降と Android Studio で動く Lesstep のプラグインです。git のリモートから組織・プロジェクト・リポジトリを読み、あなたのレビュー待ちのプルリクエストを IDE のツール ウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも動きます。プルリクエストのブランチ ポリシーを状態つきで見せるので、通っていない必須のビルドがプルリクエストの隣に出ます。Pro なら、失敗したビルド ポリシーや期限の切れたビルド ポリシーをそこからもう一度動かせます。レビューの受信箱は無料、投票・コメント・完了・作成は Pro（30日の無料試用つき）。
Azure DevOps・Azure Pipelines・.NET は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。
ほかに：MSB3644：参照アセンブリが見つからない · dotnet のタスクがプロジェクトを見つけられない · NuGet：Unable to load the service index for source · Unable to locate executable file · English