Workload feature band fallback doesn't work with workload update

[dsplaisted]

The .NET SDK will fall back to workload manifests from previous feature bands. This ensures that when we create the first builds of a new .NET SDK, workloads will continue to work without having been updated to the new feature band.

However, if there are newer versions of the workload manifests from a previous feature band, they will not be picked up with dotnet workload update. This is because the update process looks for the latest version of the workload manifest package, but the package ID is constructed using the current SDKs feature band version. So if it's falling back to a previous band, and there's a newer version of that workload manifest package, it won't find it.

To fix this we should probably first check for the latest package using the current SDK's feature band. If we don't find any packages, and the current manifest on disk is coming from falling back to a previous band's manifest, then we should also try to get the latest version of the package for that previous feature band.

We probably don't need to worry about possible feature bands in between the two. IE if we had a 6.0.300 SDK using a 6.0.100 manifest, then we should check for the latest 6.0.300 manifest, and if that's not found check for the latest version of the 6.0.100 manifest, but never check for a 6.0.200 manifest.

sdk/src/Cli/dotnet/commands/dotnet-workload/install/WorkloadManifestUpdater.cs

Line 165 in 22c4860

Dictionary<WorkloadId, WorkloadDefinition> Workloads)> CalculateManifestUpdates()

EDIT: We will also need to figure out how to differentiate between the feature band an advertising manifest is branded as and the feature band of the SDK it's advertised to, for example in WorkloadManifestUpdater.GetAdvertisingManifestVersionAndWorkloads. Right now we put advertising manifests in separate folders per feature band, but this doesn't let us model a 6.0.200 manifest being advertised to a 6.0.300 SDK, for example.

[dsplaisted]

FYI @jonathanpeppers @Redth

[Redth]

We probably don't need to worry about possible feature bands in between the two. IE if we had a 6.0.300 SDK using a 6.0.100 manifest, then we should check for the latest 6.0.300 manifest, and if that's not found check for the latest version of the 6.0.100 manifest, but never check for a 6.0.200 manifest.

I know we talked about this probably being ok, but I'm doubting that now. I guess there's added cost in this check if it needs to query nuget? But maybe it's still worth that cost to avoid unexpected behaviour here? I think even with our current baseline manifests in the installer today might be at 6.0.100 and we don't have 6.0.300 yet, so really 6.0.200 is what we want but would be missed in this case.

[joeloff]

This logic is going to complicate servicing because it will need to be mimicked.