For evaluation time, The NuGetSdkResolver is extremely slow.

Based on investigation in CoreFX, I found:

• On restored state, it added 180-400ms overhead to a single project evaluation
• On unrestored state, it added 1000-6000ms overhead to a single project evaluation

I've looked at the original design, and it's built on a incorrect premise; that its performance impact will only affect the loading state of projects that use it. The image it shows where projects are being loaded in the background via Asynchronous Solution Load (ASL) was removed from the product in 15.5.

If a project opts into this resolver, it has the following effects:

• On solution load, blocks interaction with VS until it has completed downloading & resolving the SDK.
• Increases the time it takes for the project-system to send design-time build results to Roslyn, resulting in delayed IntelliSense results
• Increases the time it takes for designers to open
• Increases the time it takes for tests to be discovered
• Increases the time it takes for VS to react to changing the active configuration
• Increases the time and blocks interaction with VS when making changes to a project, such as adding/removing a file
• Increases design-time builds for every project that references it
• Increases the time for above when switching branches

When we designed SDK resolvers, it was explicitly called out that due to them being used during evaluation - that they must be extremely fast and must not hit the network. While this only hits the network on unrestored state, it still has a large negative impact on evaluation time when the package is already downloaded.

This is the entire reason that NuGet restore does not run during the build while inside Visual Studio.

Rogue resolvers can cause Visual Studio and other IDEs to be blamed for performance and UI delay issues, please remove or change the design of this resolver to play nicely with Visual Studio.