Improve the first-run experience for workloads - detect common version mismatch scenarios and tell the user the actions to perform to resolve them

[marcpopMSFT]

Summary

Currently, upgrading the .NET SDK for either a patch version upgrade or feature band upgrade will overwrite the manifests for emsdk and runtime. There are reasons that runtime wants to update the baseline manifest with each feature band release including staying in-sync with the runtime pack version and security.

The side effect of this is that a customer upgrading their SDK (or worse, getting upgraded by Microsoft Update) will find their workloads are no longer working.

A suggestion for improving this experience for the customer is on first run of the SDK, we detect the customer is in this situation, and try to resolve it for them.

Requirements

• Only run the first run after a new SDK install
• Should only run once even if the command fails or is cancelled
• Needs to be cancellable (can it be interactive?)
• Workloads state
  • Detect workload packs have been installed for this feature band (future, detect from a prior feature band)
  • Detect that the current manifests don't match the packs installed
  • Detect that workloads were not installed using a rollback file
• Don't run this in CI
• Trigger a workload update or install trying to get the current state working between manifests and packs
• This should run anywhere were the SDK would install to a common location (windows, macos, maybe linux)

[MiYanni]

Current Status (based on requirements)

CC @marcpopMSFT @joeloff

• Only run the first run after a new SDK install
  • ✅ Currently runs immediately after the first-run experience.
• Should only run once even if the command fails or is cancelled
  • ✅ This is guaranteed to happen as isFirstTimeUse is set before the first-run experience is executed. When that finishes executing, it would have created the first-run sentinel file. Therefore, only the current run has isFirstTimeUse set true.
• Needs to be cancellable (can it be interactive?)
  • ⛔ This involves weaving a CancellationToken throughout the implementation of our CLI. That's a larger endeavor than what makes sense to do for this use case. A lot of testing involved in that, and no simple way to unit test it.
• Workloads state
  • Detect workload packs have been installed for this feature band (future, detect from a prior feature band)
    • ✅ This seems to be how the current workload install works, which is how this feature works. I haven't looked into detecting from a prior feature band.
  • Detect that the current manifests don't match the packs installed
    • ⚠️ This doesn't actually function this way (from my understanding). It is basically just brute force installing the workloads, so it doesn't do any checks between installed packs and current manifests. Let me know if this is not the desired approach.
  • Detect that workloads were not installed using a rollback file
• Don't run this in CI
  • ⚠️ I've added a DOTNET_SKIP_WORKLOAD_INTEGRITY_CHECK environment variable. This defaults so false so CI would need to have this added as true to be skipped, similar to DOTNET_NOLOGO. Let me know if there is a better approach.
• Trigger a workload update or install trying to get the current state working between manifests and packs
  • ⚠️ I don't know what this means...??
• This should run anywhere were the SDK would install to a common location (windows, macos, maybe linux)
  • ✅ Since this is simply running workload install, it already functions for every situation in which that command does. However, I still want to test the MSI installed SDK experience.

[marcpopMSFT]

Let's break out the cancellation into a separate issue. Mind filing it for tracking?

For workloads state, the idea here was that we didn't want to run this if your current workloads were working. Is there any way to detect that or is the best bet to just run an install with the no manifest update flag selected and it'll noop if there is nothing to do? Also, we didn't want to do this for a customer who isn't using workloads (ie has no packs installed). Think a WPF customer doing dotnet build shouldn't be impacted since they would have never installed a workload.

For the running in CI, are you able to use logic similar to what we already have in telemetry (maybe hoist that logic out of the telemetry area): https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/Telemetry/CIEnvironmentDetectorForTelemetry.cs#L47

For trigger, that was the bullet for actually doing the action. The rest of the bullets were describing when to do it and that was tracking the actual install or update.