-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Send "workload set not installed" messages #42683
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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). |
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:
Then (if we assume that the |
src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/WorkloadResolver.cs
Outdated
Show resolved
Hide resolved
src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/WorkloadResolver.cs
Outdated
Show resolved
Hide resolved
src/Cli/dotnet/commands/dotnet-workload/WorkloadHistoryRecorder.cs
Outdated
Show resolved
Hide resolved
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.
Looks good, but in Chet's screenshot, it seems a bit confusing that it says the workload version is |
Triage: I think we want the not installed message only when workload sets specified in global.json as the baseline manifests are installed. |
This was superseded by #43472 |
Fixes #42527
Specifically when the user runs
dotnet workload --version
ordotnet 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:
@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 #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 #42536