Avoid downloading MSBuild SDKs from NuGet on the VS UI thread

[dsplaisted]

The MSBuild NuGetSdkResolver may download NuGet packages during MSBuild evaluation, which can happen on the UI thread in VS. Some discussion of this: dotnet/msbuild#4025

We are adding some features to MSBuild SDK Resolvers to support optional SDK workloads for .NET 5. This will allow SDK resolvers to:

• Return any number of SDK paths (zero, one, or many). It will be possible to return a successful result that returns no SDK paths.
• Return MSBuild items and properties to add to the evaluation result

These features will also allow us to improve the NuGetSdkResolver experience in VS. How this could work is outlined in the "NuGet SDK Resolver" section of this designs PR: dotnet/designs#104

The proposal is this: By default, the NuGet SDK resolver would continue to work as it does today. However, in Visual Studio it would be set to a mode which would disable acquisition of the NuGet packages. In this mode, if an SDK NuGet package wasn't already available locally, the resolver would not download the package, but would add a MissingMSBuildSDK item with the name and version of the SDK that needs to be downloaded.

The project system would check for MissingMSBuildSDK items after the project is evaluated. If there are any, the project system would not load the project normally. It would launch an async acquisition process to download the NuGet packages, while showing appropriate UI (for example a spinning progress bar, or "loading..." text by the project in Solution Explorer). When the package acquisition finishes, the project system would reload the project.

We may need to add the ability for resolvers to read global properties in order for VS to communicate to the NuGetSdkResolver that it should run in this different mode.

[davkean]

I would much prefer the communication to be something as simple as:

• We get a list of missing packages
• We pass these to an API (from NuGet) and it downloads it.

We can handle the prompt, etc, but using the project evaluation as side-effect of acquiring the packages would be very hard to coordinate with the solution and the project load life cycle.

[davkean]

@dsplaisted Given SDKs can refer to other SDKs, how will MSBuild be able to provide a complete set of MissingMSBuildSDK items to avoid the load project -> prompt -> load project -> prompt?

[drewnoakes]

@davkean might be best for the user if the prompt cleared itself once everything's loaded, regardless of how many downloads occur. The user shouldn't have to interact with the message.

[dsplaisted]

I discussed this with @davkean yesterday. The proposal is that MSBuild would provide a list of SDKs to download. There are some cases where we couldn't know the full dependencies on the first evaluation. This can happen if a NuGet SDK imports another NuGet SDK, or if a NuGet SDK ends up adding a dependency on an optional workload that would need to be installed via in-product acquisition.

As Drew notes, the experience is mitigated if there isn't a prompt the user has to click through in order to download NuGet packages.

Dave suggested that a cheaper first step would be to fail the load in VS if there were unresolved NuGet SDKs, with a message that the project needs to be built from the command line first in order to restore the packages, so that VS can open the project.

[jjmew]

Triage: @davkean is this something that you should own or should we give it to someone else?

[jjmew]

I am following up with @marcpopMSFT

[jjmew]

The idea is that we will block it and ask the user to use the command line to restore. Later on we might do something beyond that.