Trigger In-Product Acquisition for optional SDK workloads

[dsplaisted]

When opening a project that requires an optional SDK workload (such as iOS or Android) that isn't installed, the project system should trigger an in-product acquisition experience to allow the user to click through to install the required workload. The design for this (from the MSBuild / SDK side) is here: dotnet/designs#104

[dsplaisted]

FYI @jjmew, I've filed this issue to track the in-product acquisition experience we've discussed a few times.

[jjmew]

Triage: @davkean do you have a recommendation who should work on this?

[jjmew]

@cartermp We need your help designing this. This is high priority. Please work with @davkean

[cartermp]

Yep, happy to do it. I'm not quite clear on if we get access to evaluation results at "in product acquisition time", since my understanding is that the VS system triggers this when it attempts to load a project. Can IPA also be triggered after evaluation? @davkean or @jmarolf would know more.

@dsplaisted The question in your spec is a good one:

QUESTION: Will it be OK to put this mapping of .NET workload IDs to VS workload/component IDs in the workload manifest packages? Or do we need to supply it some other way

I'd defer to @jmarolf since he authored most of the .NET manifests and probably has the best idea for where that mapping should live. What VS tells the installer to acquire ultimately depends on how things are factored and what level of granularity (VS Workload, VS Component Group, VS Component) we're expecting with .NET SDK workloads and what state someone's VS might be in w.r.t what they have installed. @dsplaisted are you the owner of that?

Side Note: the terminology here is going to get confusing for everyone involved 😿

[davkean]

@cartermp Let's sync up, I have a good idea how to approach based on existing infrastructure we already have in the product.

[davidwengier]

Plan: (Service names open to change..)

• Solution-level IProjectRetargetingManager service that waits to be notified that projects have identified their problems (AB#1124216)
• ConfiguredProject-level (configured? unconfigured?) service IProjectRetargetCheckManager that hooks up to evaluation on project load (IProjectDynamicLoadComponent)
• Individual IProjectRetargetCheckProvider services that each check for a specific issue
  • There will actually be multiple interfaces for this, not just one, depending on what the resolution to the problem is based on the design (AB#1124250). Broadly:
    • Install something via VS Setup (AB#1124247)
    • Retarget something in the project to a different version that is on the machine (AB#1124248)
    • A link for information about manual resolution steps (AB#1124249)
  • It is an open question whether these three resolution types are separate from the IProjectRetargetCheckProvider or take the place of it, and if the latter, whether thats via different interfaces or different abstract base classes
• The IProjectRetargetCheckManager consumes the IProjectRetargetCheckProvider instances and calls them to do checks
• When evaluation data comes in, checks are performed and if problems are found, IProjectRetargetCheckManager reports them, or produces output of them
• An UnconfiguredProject-level service listens for data from IProjectRetargetCheckManager instances, considering only implicitly active projects (see: https://github.com/dotnet/project-system/blob/master/src/Microsoft.VisualStudio.ProjectSystem.Managed.VS/ProjectSystem/VS/PackageRestore/PackageRestoreUnconfiguredInputDataSource.cs#L35)
  • This service aggregates, de-dupes and/or resolves conflicts, and reports the problems, or at least their existence to the IProjectRetargetingManager
• Once the solution is loaded (???) the IProjectRetargetingManager calls IVsTrackProjectRetargeting2.CheckSolutionForRetarget (???) to kick off the retargeting
• Retargeting is handled by a IProjectRetargetingProvider that reports the problems found above

[davidwengier]

https://app.diagrams.net/#Hdavidwengier%2Fproject-system%2FTestingInProduceAcquisition%2Fdocs%2Frepo%2Fcontent%2FIn%20Product%20Acquisition.drawio