Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Closed
wants to merge 8 commits into from

Conversation

Forgind
Copy link
Member

@Forgind Forgind commented Aug 13, 2024

Fixes #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:
image

(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

@ghost ghost added Area-Workloads untriaged Request triage from a team member labels Aug 13, 2024
@marcpopMSFT marcpopMSFT requested a review from dsplaisted August 13, 2024 20:55
@dsplaisted
Copy link
Member

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
Copy link
Member Author

Forgind commented Aug 16, 2024

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.

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.
@baronfel baronfel added this to the 9.0.1xx milestone Aug 28, 2024
@Forgind Forgind changed the base branch from main to release/9.0.1xx August 28, 2024 20:55
@Forgind Forgind requested review from a team as code owners August 28, 2024 20:55
@Forgind Forgind removed request for a team August 28, 2024 20:55
@baronfel
Copy link
Member

image

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

@baronfel baronfel added the consider-for-documentation Issues where some of the information in the discussion may be appropriate to add to documentation label Aug 29, 2024
@dsplaisted
Copy link
Member

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
Copy link
Member

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

@dsplaisted
Copy link
Member

This was superseded by #43472

@dsplaisted dsplaisted closed this Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Workloads consider-for-documentation Issues where some of the information in the discussion may be appropriate to add to documentation untriaged Request triage from a team member
Projects
None yet
4 participants