dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.71k stars 1.06k forks source link

[NETSDKE2E]The workload version in ‘dotnet workload --version| --info“ should show the workload set version rather than the manifest version after set update mode to workload-set. #42527

Open vdanche opened 2 months ago

vdanche commented 2 months ago

Repro steps: 1.Install 8.0.400 SDK on clean OS(win11-x64) 2.dotnet workload --version / dotnet workload --info as below image 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" image image

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

NicoleWang001 commented 2 months ago

It will not happen after running 'dotnet workload update' image

dsplaisted commented 2 months ago

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.

NicoleWang001 commented 2 months ago

@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? image

NicoleWang001 commented 2 months ago

@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. image

image

Forgind commented 2 months ago

@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? image

I think you're right that it would be reasonable to add that message. The extra line in dotnet workload list is as intended.

Forgind commented 2 months ago

@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. image

image

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.