NETCoreSdkResolver should give a clear error message when preview SDK is rejected due to UsePreviews=false

[KirillOsenkov]

Currently the experience we see when a preview SDK is rejected due to DisallowPrerelease()
https://github.com/dotnet/cli/blob/bfffcb23ba270640b355e729f36b34c04fad0121/src/Microsoft.DotNet.MSBuildSdkResolver/VSSettings.cs#L75

is not good. It's a generic failed to load .NET SDK error, and it's super hard to figure out that the SDK was actually found, but it was pre-release and the checkbox wasn't set.

See related:
dotnet/roslyn#34927

If I wasted four hours figuring this out and debugging through the SDK resolver, the UX here should really be improved.

[nguerrera]

The usual case is that another sdk is found that is rtm and there we have no error to improve. The rtm sdk picked is by design. Often that sdk will then complain if your project is targeting a preview from newer than it, but by the time it sees the tfm, it’s too late.

We can improve the error if no other sdk is available but this isn’t the common case. (Edit: it is actually common for arcade style builds with a private sdk, and this case can be fixed easily. Using this bug to track that.)

We’re discussing a bunch of diagnostic improvements (including logging for the successful rtm resolution when you really wanted preview, but we can't tell that until it's too late), and I agree it is very confusing.

Thanks for the feedback.

[nguerrera]

Putting in 2.2.3xx to improve the error in 16.1 for the simple case that roslyn/arcade hit on the command line with private preview on PATH and no multi-level lookup. In that case, there is no other SDK that can be picked, we can easily refine the message to indicate that there was one, but it was preview and previews are not enabled.

[nguerrera]

We'll be looking at bigger ways to improve the diagnostics all up, but I'll let this issue track the simple case and use another issue to track the rest.