More detailed error message when SDK is not found

[KirillOsenkov]

Currently when global.json specifies an SDK that's not installed, here's the error you get:

Unable to locate the .NET SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.

This error is not nearly detailed enough. It is also very important as it's a gateway to our entire ecosystem (think someone new to .NET clones a repo, tries to build and sees this). We need to make this first run experience as smooth as possible, and now it's anything but.

Ways I see that we can improve this message:

1. be explicit whether there was a global.json or not, and if yes, what was the exact location
2. which version is expected by global.json?
3. which versions are currently installed and were reachable by the resolver?
4. what to do next? Provide a URL that is as precise as possible to download (perhaps get the exact URL to the blob)

Long term we need to think about potentially downloading and installing the SDK automatically and on demand if it wasn't found. Perhaps ask "would you like to download and install it now?" and have a -force flag or something that does it silently (for CI scenarios). This way we can avoid having a separate Use .NET SDK CI step, and we could just do msbuild /r /ensuresdk or something to make sure we can build the repo in a single automatable step.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[baronfel]

I agree with this - the message could be much more actionable. For the last point, we'd like to provide a command-line action to download specific SDKs and runtimes for 7.0, so we should supply that when that work is done.

There are two related messages here:

• Unable to locate the .NET SDK
• Unable to locate the .NET SDK as specified by global.json

In the first case, the native code resolver couldn't find an SDK directory. In the second case, the resolved directory didn't have any SDKs that matched the requested one as specified by global.json. In either case, we should add some information about expectations.

[richlander]

Here is our related prior art to align with:

• Update error message for runtime not found runtime#67564
• Disable multi-level lookup by default runtime#67022
• Remove 'reflecting any global.json' from info label #24541

[baronfel]

We can ask the hostfxr for details about SDK resolution: dotnet/runtime#68355

The global.json path (if one exists) and the requested version will be provided regardless of resolution success or failure, so we should adapt to read both of those values and flow them into our error messages.