Workload Install Type Can be Incorrect with Manifests Authored for Younger SDKs

[nagilson]

Describe the bug

Running dotnet workload --info can sometimes report the incorrect install type. For example, it may say that MSI based workloads are FileBased even though the SDK is running under MSI mode and those workloads are installed via MSIs.

To Reproduce

You need to have an SDK with a version that owns the manifests but is different from the Manifest Version.

What happens is that the SDK looks for an MSI sentinel file under metadata in program files using the Manifest Version, such as 8.0.100. But if the SDK version is different, such as 8.0.200, the MSI sentinel file will be in a folder called 8.0.200, not a folder with the manifest version 8.0.100.

The result of the lookup will be whatever 8.0.100 is, whether or not the SDK that owns the manifests (8.0.200) is file based, or MSI based. In this example, because the 8.0.100 folder in metadata does not exist, it will report the MSI workloads installed by the MSI SDK (8.0.200) to be file based, which is incorrect. However, if 8.0.200 is file based but uses 8.0.100 version manifests, and there is an SDK that's 8.0.100 and MSI based on the system, I'd imagine this bug would work in the opposite direction too.

Proposal

Perhaps we should have an msi file for each workload, or update this logic some other way.

[dsplaisted]

We are using the workload manifest feature band where we should be using the feature band of the current SDK. Here is the line where this is happening:

sdk/src/Cli/dotnet/commands/dotnet-workload/WorkloadCommandParser.cs

Line 91 in a8819e9

reporter.WriteLine($" {WorkloadInstallType.GetWorkloadInstallType(new SdkFeatureBand(workloadFeatureBand), dotnetPath).ToString(),align}"

We should change that to this:

reporter.WriteLine($"       {WorkloadInstallType.GetWorkloadInstallType(new SdkFeatureBand(Utils.Product.Version), dotnetPath).ToString(),align}"

[vdanche]

@Forgind This issue will not have a fix in net8.0, right? still repro on 8.0.402 sdk

FYI @marcpopMSFT

[Forgind]

The PR to fix this was merged into main last week, not release/8.0.4xx, so it won't be fixed until 9.0

[vdanche]

@Forgind checked with 9.0.100-rc.2.24453.20 exe install,
The install type for maui is displayed correctly, but install type for aspire is dislayed "FileBased", is it expected?

[Forgind]

/cc: @dsplaisted to take a look

[dsplaisted]

It looks like this was merged to main after we had branched for 10.0. I've opened a PR to backport it to 9.0: #43231

[vdanche]

Checked with 9.0.100-rc.2.24468.2 SDK exe install, install type for aspire is dislayed as "Msi" now