Avoid downloading MSBuild SDKs from NuGet on the VS UI thread

The MSBuild NuGetSdkResolver may download NuGet packages during MSBuild evaluation, which can happen on the UI thread in VS. Some discussion of this: https://github.com/microsoft/msbuild/issues/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: https://github.com/dotnet/designs/pull/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.

[jeffkl]

How have you determined the worst problems have been improved here?

I have made some big improvements around the whole scenario. There’s a lot more going on than just downloading a package. For each design-time build, a global.json is searched for and deserialized, NuGet.Config is loaded, then the disk is searched for an existing package, then finally a package is downloaded. Also, MSBuild’s SDK resolution APIs were launching a lot of threads to handle out-of-proc design-time builds (evaluations) in the main node which could lead to thread starvation. I also moved the NuGet-based MSBuild project SDK resolver down in priority so that the .NET SDK resolver runs first in case its just a built in SDK being resolved.

I have more work to do in this area so don’t think I’m done improving things.

https://github.com/NuGet/Home/issues/11441

[jeffkl]

Did it take 15 minutes to download a package? I’m assuming that there was some thread starvation going on where a ton of threads were all trying to resolve an SDK and it took a lot longer to get a nupkg.

I have never been able to reproduce the issue. I’ve generated a large solution that references five different SDKs. I’ve injected test SDK resolvers that have sleeps, and I’ve tried clone repos that exhibit the problems but I have never been able to get it to happen live for me to debug.

I am not making wild claims that its all fixed. I have been making changes to the whole stack that should improve the experience that should make a difference. Do you have time to help me get some data that I can use to make meaningful comparisons?