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

[workloads] The sdk added exclusions to to workload manifests that were in active use #30175

Open
lewing opened this issue Jan 28, 2023 · 6 comments
Assignees
Milestone

Comments

@lewing
Copy link
Member

lewing commented Jan 28, 2023

As part of dealing with issues due to manifest renaming around net7 rc1 the sdk explicitly banned workload manifest names that were still in active use in main and no sdk/installer tests identified that this situation made the .NET8 wasm-tools workload uninstallable. At a bare minimum the ban list tests should verify that no banned workload name in the sdk is still in active use as a bundled workload in dotnet/installer

@lewing
Copy link
Member Author

lewing commented Jan 28, 2023

This made dotnet/runtime#80401 a requirement for preview1

@marcpopMSFT
Copy link
Member

The list is here: https://github.com/dotnet/sdk/blob/main/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs#L18

@lewing I'm not 100% sure of the ask in this issue. I think you want us to verify that the exclusion list doesn't include an item in the known workload list. Are you interested in bringing back the workload name without .current (ie should we just remove that from the exclusion list for 8)?

@marcpopMSFT marcpopMSFT modified the milestones: 8.0.1xx, 9.0.1xx Sep 15, 2023
@lewing
Copy link
Member Author

lewing commented Oct 31, 2023

net6.0 is still using that mono.toolchain name, and now VS isn't loading the workload for net6.0

The thing I was referring to is https://github.com/dotnet/sdk/blob/main/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs#L25

@lewing
Copy link
Member Author

lewing commented Oct 31, 2023

This appears to be the cause of mono/SkiaSharp#2640
image

@lewing
Copy link
Member Author

lewing commented Oct 31, 2023

I have verified that manually renaming the workload directory inside the sdk causes it to function correctly

image

@lewing
Copy link
Member Author

lewing commented Oct 31, 2023

The list is here: https://github.com/dotnet/sdk/blob/main/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs#L18

@lewing I'm not 100% sure of the ask in this issue. I think you want us to verify that the exclusion list doesn't include an item in the known workload list. Are you interested in bringing back the workload name without .current (ie should we just remove that from the exclusion list for 8)?

Beyond not doing this sort of thing again without a heads up, we could avoid the customer issue by making the outdated list apply by tfm if we have that information available at this point in the resolution.

@marcpopMSFT marcpopMSFT modified the milestones: 9.0.1xx, Backlog Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants