Send "workload set not installed" messages

[Forgind]

Fixes https://github.com/dotnet/sdk/issues/42527

Specifically when the user runs dotnet workload --version or dotnet workload --info after requesting a workload set via the global.json but it isn't installed, finding only the baseline manifest, or switching to WorkloadInstallType.WorkloadSets and not finding a workload set.

Sample output:

PS C:\bugs\temp> dotnet workload config --update-mode workload-set
Successfully updated workload install mode to use workload-set.
PS C:\bugs\temp> dotnet workload --version
Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.
9.0.100-manifests.4bec43ae

PS C:\bugs\temp> dotnet workload --info
Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.
 Workload version: 9.0.100-manifests.4bec43ae
Configured to use workload sets when installing new manifests.
There are no installed workloads to display.

PS C:\bugs\temp> dotnet --info
.NET SDK:
 Version:           9.0.100-dev
 Commit:            7047bd2f34
Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.
 Workload version:  9.0.100-manifests.4bec43ae
 MSBuild version:   17.12.0-preview-24407-03+6bc91d5e2

PS C:\bugs\temp> dotnet workload --version
Workload version 9.0.100, which was specified in C:\bugs\temp\global.json, was not found. Run "dotnet workload restore" to install this workload version.
9.0.100

@baronfel, what do you think of these messages?

I'm also a bit undecided as to whether this is a bug or not:

(Not including the stack trace part—that should disappear with https://github.com/dotnet/sdk/pull/42630.)

But I'm a bit undecided as to what it should look like if a user specifies a particular workload set in a global.json then tries to run something like dotnet --info. It normally prints out the installed workload manifest versions, among other things, and that should lead to the FileNotFoundException it throws, but it feels weird to have that in the middle of the info spew. Thoughts?

This will conflict with https://github.com/dotnet/sdk/pull/42536

[dsplaisted]

This is helpful, but once we switch the default to use workload sets, we shouldn't see the ShouldInstallAWorkloadSet message anymore.

Given that, I don't think the OnlyBaselineManifestFound message is really necessary. If you install any workloads the SDK will update the manifests by default anyway (and show you a message with the old and new workload versions).

[Forgind]

I agree about ShouldInstallAWorkloadSet—I mostly added that because for earlier versions, we weren't finding the baseline manifests either, and that would've fired—but I'm not convinced about OnlyBaselineManifestFound. Regardless of the default, if someone does this:

dotnet workload config --update-mode loose-manifests
dotnet workload install maui-android
...
dotnet workload config --update-mode workload-set

Then (if we assume that the ... included a lot of updates/installs, and the baseline workload set is now far behind), customers may suddenly see a fairly substantial regression as they try to use the old manifests pinned in the baseline workload set. I think they'd ideally be able to see a message about that.

[baronfel]

Nice and in-lined, thank you! The experience of this LGTM, so as soon as the team reviews we should :shipit:

[dsplaisted]

Looks good, but in Chet's screenshot, it seems a bit confusing that it says the workload version is 9.0.100-manifests.<hash> (not installed). That seems to imply that the baseline manifest version it's displaying isn't installed, when that version is installed.

[marcpopMSFT]

Triage: I think we want the not installed message only when workload sets specified in global.json as the baseline manifests are installed.

[dsplaisted]

This was superseded by https://github.com/dotnet/sdk/pull/43472