sdk
sdk copied to clipboard
Workload Install Type Can be Incorrect with Manifests Authored for Younger SDKs
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.