Open vdanche opened 2 months ago
It will not happen after running 'dotnet workload update'
This is the expected behavior. Changing the update mode doesn't actually install anything, you also need to do an update to install a workload set and thus change the version that's displayed.
Perhaps we should add a message when you change the mode suggesting that you run an update.
@dsplaisted I think it is better to add this message. Because if changed the mode but did not run an update, output in 'dotnet workload list' leads misunderstanding - workload version shows manifest, but workload info shows workload-set.
One more thing, with workload-set mode, workload version is shown in output of 'dotnet workload list'. But it is did not shown with manifest mode. Is it expected as well?
@dsplaisted We got the same behavior (still show the manifest version after changing the mode without running an update) with .NET 8.0.400 using exe & zip install and .NET 9 Preview7 using exe install. But different behavior with .NET 9 Preview 7 using zip install - it shows the workload set version after changing the mode without running an update. It is really confused.
@dsplaisted I think it is better to add this message. Because if changed the mode but did not run an update, output in 'dotnet workload list' leads misunderstanding - workload version shows manifest, but workload info shows workload-set.
One more thing, with workload-set mode, workload version is shown in output of 'dotnet workload list'. But it is did not shown with manifest mode. Is it expected as well?
I think you're right that it would be reasonable to add that message. The extra line in dotnet workload list
is as intended.
@dsplaisted We got the same behavior (still show the manifest version after changing the mode without running an update) with .NET 8.0.400 using exe & zip install and .NET 9 Preview7 using exe install. But different behavior with .NET 9 Preview 7 using zip install - it shows the workload set version after changing the mode without running an update. It is really confused.
I suspect it's finding the baseline workload set when using 9.0, in which case I think that's probably ok. If that's the case, I do think we should display a message then as well to say that we'd found the baseline workload set; if we have a customer who hasn't updated their SDK in a long time and updated their workloads several times but haven't yet installed a new workload set.
Repro steps: 1.Install 8.0.400 SDK on clean OS(win11-x64) 2.dotnet workload --version / dotnet workload --info as below 3.Dotnet workload config --update-mode workload-set 4.After workload-set mode is set, check if workload version is displayed well after running workload --version / dotnet workload --info
Expected Result: Workload version is displayed as "8.0.400"
Actual Result: Workload version is still "8.0.400-manifests.b6724b7a"
dotnet --info: .NET SDK: Version: 8.0.400 Commit: 36fe6dda56 Workload version: 8.0.400-manifests.b6724b7a MSBuild version: 17.11.3+0c8610977
Runtime Environment: OS Name: Windows OS Version: 10.0.22631 OS Platform: Windows RID: win-x64 Base Path: C:\Program Files\dotnet\sdk\8.0.400\
.NET workloads installed: Configured to use workload sets when installing new manifests. There are no installed workloads to display.
Host: Version: 8.0.8 Architecture: x64 Commit: 08338fcaa5
.NET SDKs installed: 8.0.400 [C:\Program Files\dotnet\sdk]
.NET runtimes installed: Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found: None
Environment variables: Not set
global.json file: Not found
Learn more: https://aka.ms/dotnet/info
Download .NET: https://aka.ms/dotnet/download