Skip to content
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

[NETSDKE2E][Workload set]With 9.0.104 SDK installed on win-x64, Warning "The specified version does not contain a valid major, minor, and patch version: '9.0.102.1' displays when switch back to loose manifests if workload set version is "9.0.102.1" #46946

Open
vdanche opened this issue Feb 19, 2025 · 4 comments
Labels
Area-Workloads untriaged Request triage from a team member

Comments

@vdanche
Copy link
Member

vdanche commented Feb 19, 2025

Repro steps:
1.Install 9.0.104 SDK on win-x64.
2.Run below command
dotnet workload install maui
Dotnet workload update --version 9.0.102.1
Dotnet workload config --update-mode manifests
3.Dotnet workload update

4.Check if there is any warning and error.

Expected Result
There is no any warning and error

Actual Result:
Step3: Warning: Workload garbage collection failed with error: The specified version does not contain a valid major, minor, and patch version: '9.0.102.1' displays when switch back to loose manifests if workload set version is "9.0.102.1"

Image

Note:
if we continue uninstalling maui, below error happens, but it had been uninstalled

Image

dotnet --info
.NET SDK:
Version: 9.0.104
Commit: 2750432faa
Workload version: 9.0.100-manifests.34e45f8a
MSBuild version: 17.12.27+e0b90a9a8

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.104\

.NET workloads installed:
[maui]
Installation Source: SDK 9.0.100
Manifest Version: 9.0.14/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.14\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.3
Architecture: x64
Commit: 831d23e561

.NET SDKs installed:
9.0.104 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 9.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 9.0.3 [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

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Feb 19, 2025
@vdanche vdanche changed the title [NETSDKE2E][Workload set]With 9.0.104 SDK installed on win-x64, Warning "The specified version does not contain a valid major, minor, and patch version: '9.0.102.1' when switch back to loose manifests if workload set version is "9.0.102.1" [NETSDKE2E][Workload set]With 9.0.104 SDK installed on win-x64, Warning "The specified version does not contain a valid major, minor, and patch version: '9.0.102.1' displays when switch back to loose manifests if workload set version is "9.0.102.1" Feb 19, 2025
@v-ainigao
Copy link

This issue also repro's on arm64OS.
Image

@ChenhuiYuan01
Copy link
Member

This issue also repro's on Linux
Image

@YingyingYuan9
Copy link
Member

This issue also repro's on MAC
Image

@Forgind
Copy link
Member

Forgind commented Feb 20, 2025

That PR targeted release/9.0.2xx, so it never made it into release/9.0.1xx.
The problematic line that that was trying to fix is here:
sdk/src/Cli/dotnet/commands/dotnet-workload/install/WorkloadGarbageCollector.cs at v9.0.103 · dotnet/sdk. Note that it is still present in release/9.0.1xx.

I believe users will hit this if they do the following:

  1. They install a workload set with a fourth version part (9.0.102.1 in this case)
  2. They try to do garbage collection for any reason

The reason that line fails in that scenario is that we tried to parse a 4-part version into a ReleaseVersion. ReleaseVersions only support up to three version parts. We only do that parsing as part of trying to sort the workload set versions, however, so there's no reason we need to parse them into ReleaseVersions if we can otherwise compare them. That's what the below fix does.

The fix is to backport #45263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Workloads untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

5 participants