From 4214861adf915af0a14ab14f10253baf1b03a5fc Mon Sep 17 00:00:00 2001
From: Forgind <12969783+Forgind@users.noreply.github.com>
Date: Mon, 12 Aug 2024 10:51:26 -0700
Subject: [PATCH] Find baseline workload set in 8.0.100 folder (#42435)

Summary
This effectively contains one commit that went into main previously but never made it into 8.0.4xx despite needing it.

This was missed for multiple reasons:

The commit is already in main/9.0-previews, and the change that led to the user-visible issue was only merged in 8.0.4xx, which limits its impact.
It does not reproduce until sdk and installer are put together, which means it wasn't even testable with the 8.0.4xx SDK unless it was inserted into the installer repo.
It does not reproduce with MSI-based installs, as their layout is different.
Fixes #42357 and #42358

Customer Impact
The impact of the bug is that any operation involving workload garbage collection will fail. More specifically, all workload sets are always considered 'workload sets to keep,' including the baseline workload set, during garbage collection. That baseline workload set is not in the correct folder, however, which means that although we can 'discover' it when we do an initial 'find all workload sets' step, when we move to resolve it, we can't find it. This then throws an exception. This PR enables us to find it. Though a workaround, this should work for 8.0.4xx in the long term; main has both this workaround and a better long-term fix.

Regression?
This is a fix for a regression in 8.0.4xx.

Testing
I built this change, overlaid it on an SDK with the baseline workload set, verified that that workload set was discovered during garbage collection and resolved as intended, and verified that the remainder of the operation completed successfully.

Risk
The risk of this fix is low. It permits a code path that otherwise was not otherwise available.
---
 .../SdkDirectoryWorkloadManifestProvider.cs               | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs b/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs
index 22a7c18d3b47..2aca0c68dbd5 100644
--- a/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs
+++ b/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/SdkDirectoryWorkloadManifestProvider.cs
@@ -123,6 +123,7 @@ public void RefreshWorkloadManifests()
             _installStateFilePath = null;
             _useManifestsFromInstallState = true;
             var availableWorkloadSets = GetAvailableWorkloadSets(_sdkVersionBand);
+            var workloadSets80100 = GetAvailableWorkloadSets(new SdkFeatureBand("8.0.100"));
 
             bool TryGetWorkloadSet(string workloadSetVersion, out WorkloadSet? workloadSet)
             {
@@ -142,6 +143,13 @@ bool TryGetWorkloadSet(string workloadSetVersion, out WorkloadSet? workloadSet)
                     }
                 }
 
+                // The baseline workload sets were merged with a fixed 8.0.100 feature band. That means they will always be here
+                // regardless of where they would otherwise belong. This is a workaround for that.
+                if (workloadSets80100.TryGetValue(workloadSetVersion, out workloadSet))
+                {
+                    return true;
+                }
+
                 workloadSet = null;
                 return false;
             }