Improve Diagnosability of SDK Resolve Failure

[msfcolombo]

When running msbuild, dotnet build or dotnet msbuild in the project below, I get the error:

C:\repo-path\sample\dirs.proj : error MSB4236: The SDK 'Microsoft.Build.Traversal' specified could not be found.

Here's the project:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" Sdk="Microsoft.Build.Traversal">
  <ItemGroup>
     <ProjectFile Include="Sample\Sample.csproj" />
     <ProjectFile Include="SampleTest\SampleTest.csproj" />
  </ItemGroup>
</Project>

When running with -v diag, I've noticed that it does not attempt to install or restore the SDK.

I don't know how to install that SDK manually either. Documentation at https://github.com/microsoft/MSBuildSdks and https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk doesn't explain how to install. They just say that restore is automatic.

I also attempted -target:Restore but it says Target "Restore" skipped. The target does not exist in the project and SkipNonexistentTargets is set to true.

msbuild version

C:\repo-path\sample>"c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe" --version
Microsoft (R) Build Engine version 16.9.0+5e4b48a27 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.9.0.16703

dotnet installed SDKs

C:\repo-path\sample>dotnet --list-sdks
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.523 [C:\Program Files\dotnet\sdk]
2.1.815 [C:\Program Files\dotnet\sdk]
2.2.110 [C:\Program Files\dotnet\sdk]
2.2.300 [C:\Program Files\dotnet\sdk]
3.0.103 [C:\Program Files\dotnet\sdk]
3.1.114 [C:\Program Files\dotnet\sdk]
5.0.202 [C:\Program Files\dotnet\sdk]

The problem happens when I select SDK 3.1.114 or 5.0.202. I confirm that in both cases it's searching the msbuild SDK on directory C:\Program Files\dotnet\sdk\{dotnet-SDK-version}\Sdks\Microsoft.Build.Traversal\Sdk, and it's not finding there because it does not exist.

I don't know how to install the msbuild SDK manually or what to do to fix the environment.

[msfcolombo]

I found the issue. Missing global.json file. Please improve the error message, or add more stuff to diagnostics verbosity. It tells absolutely nothing about search for global.json.

Thanks!

[jeffkl]

This will be improved due to #6312 which will fail the build at least

This documentation explains how to use MSBuild project SDKs: https://github.com/Microsoft/MSBuildSdks#how-can-i-use-these-sdks

This does as well: https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk?view=vs-2019#how-project-sdks-are-resolved

A NuGet-based resolver that queries your configured package feeds for NuGet packages that match the ID and version of the SDK you specified.

This resolver is only active if you specified an optional version. It can be used for any custom project SDK.

Its really hard to know that the reason that an SDK couldn't be resolved was because a version wasn't specified because each SDK resolver may or may not need a version.

[msfcolombo]

Besides that, logs should tell that it attempted to open global.json to resolve the version, and could not find the file.

[rainersigwald]

I feel like an aspect of the original design of SDK resolvers was lost here: each resolver can fail to find an SDK, and that's fine because there's a chain of them and the next one might. But if none of them do, we should emit the errors from each resolver, which would help pinpoint this.

I thought we had a preexisting bug for this but I can't find it now, so this is it.

[msfcolombo]

Possibly related: dotnet/sdk#18048.

[am11]

Microsoft.Build.Traversal SDK's inability to provide source of problematic project (even with -v diag) is a pain point when things stop working. While looking into .NET 10 change that broke community platform dotnet/runtime#105004 (comment), I noticed that the portion of diagnostics log show:

2024-10-04T06:47:27.3816679Z                        CACHE https://api.nuget.org/v3/vulnerabilities/index.json (TaskId:40)
2024-10-04T06:47:27.3825097Z                        CACHE https://api.nuget.org/v3-vulnerabilities/2024.10.02.05.41.40/vulnerability.base.json (TaskId:40)
2024-10-04T06:47:27.3827114Z                        CACHE https://api.nuget.org/v3-vulnerabilities/2024.10.02.05.41.40/2024.10.03.17.41.44/vulnerability.update.json (TaskId:40)
2024-10-04T06:47:50.6777279Z                      Skipping restore for project '/runtime/src/coreclr/.nuget/ILCompiler.Reflection.ReadyToRun.Experimental/ILCompiler.Reflection.ReadyToRun.Experimental.pkgproj'. The project file may be invalid or missing targets required for restore. (TaskId:40)
2024-10-04T06:47:50.7808669Z                      Skipping restore for project '/runtime/src/coreclr/tools/dotnet-pgo/dotnet-pgo-pack.proj'. The project file may be invalid or missing targets required for restore. (TaskId:40)
2024-10-04T06:47:53.6892510Z 06:47:53.688     3>/runtime/.dotnet/sdk/9.0.100-rc.1.24452.12/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'freebsd-x64'. [/runtime/Build.proj]
2024-10-04T06:47:53.6920542Z ##vso[task.logissue type=error;sourcepath=/runtime/.dotnet/sdk/9.0.100-rc.1.24452.12/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets;linenumber=158;columnnumber=5;code=NETSDK1084;](NETCORE_ENGINEERING_TELEMETRY=Restore) There is no application host available for the specified RuntimeIdentifier 'freebsd-x64'.
2024-10-04T06:47:53.6924186Z 06:47:53.688     3>/runtime/.dotnet/sdk/9.0.100-rc.1.24452.12/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(158,5): error NETSDK1084: There is no application host available for the specified RuntimeIdentifier 'freebsd-x64'. [/runtime/Build.proj]

which doesn't say anything about which traversed node the project failed to restore. dotnet-runtime/Build.proj with traversal SDK means pretty much any project in that repo.

[rainersigwald]

This issue was addressed with #7882. @am11 I don't think I understand your concern, can you elaborate in a fresh issue?