catch-22 regarding running dotnet restore vs. dotnet workload restore first

[AArnott]

Describe the bug

My CI build is broken on some agents because there seems to be a catch-22 regarding whether to run dotnet restore or dotnet workload restore first.

If I run dotnet restore first, it errors out saying "error NETSDK1147: To install these workloads, run the following command: dotnet workload restore".

If I run dotnet workload restore first, it errors out saying "The SDK 'Microsoft.Build.Traversal' specified could not be found."

Yes, I have traversal projects. And in fact the root of my restore operation is a dirs.proj.

To Reproduce

I suspect all you need is a dirs.proj that points to a project that requires android, iOS or anything else requiring a workload.
Then, on a computer that does not already have a nuget cache with Microsoft.Build.Traversal or the required workload installed, try restoring.

Further technical details

SDK Version: 9.0.100

This happens on mac, windows and linux agents. These are custom agents, BTW, so they don't have a bunch of workloads pre-installed as the Azure Pipelines Hosted agents may have.

[baronfel]

More reason to get traversal and notargets SDKs into the MSBuild core @rainersigwald :-/

@AArnott I think as a workaround if you know the workloads you require you can explicitly call 'dotnet workload install ' to get around this. All workload restore does is call a target to try and determine this list on your behalf, so calling install yourself will be strictly faster not to mention not requiring the 'dotnet restore' to have completed.

[AArnott]

Thanks for the suggestion.

I'm working around this by running dotnet workload restore some.sln and reserving use of the traversal project for the subsequence dotnet restore command.

[marcpopMSFT]

Moving to the backlog for now pending the traversal sdk work. We could also consider a way of hardcoding the workloads you wanted for restore or changing how workload restore gets the list but holding off on that investment for now.

[AArnott]

That's fine. I have a workaround.

But IMO it's bigger than the traversal SDK. In general, a project that uses any MSBuild SDK and requires a dotnet workload is SOL.

I can workaround it because these two requirements for me are in different projects, so I can focus my dotnet workload restore command on projects that need it, and dotnet restore can then run on all the projects. But if these projects are the same or intermingled by project references going both directions, you're sunk.

Alternatively, a workaround as @baronfel mentioned is to manually install with dotnet workload install, which avoids the dotnet workload restore command altogether.

[baronfel]

Linking #45216 because it's probably my preferred approach to the problem.

dotnet workload restore is trying to be smart and figure out what workloads to install, but if there were a specific list (either user specified via dotnet workload install X Y Z or in a place like global.json as #45216 requests) then dotnet workload restore could consult that and skip the build. The gesture's intent would remain, but it would become more reproducible.