dotnet / dotnet/msbuild

NuGetSdkResolver adds significant overhead to evaluation and should not be used

Open
#4,025 67 comments 10 reactions 0 assignees View on GitHub
Area: Performance backlog For consideration Partner request Priority:1 triaged
Dominant language
C#
Stars
5.5k
Forks
1.5k
Avg merge
1d 8h
Merged PRs (30d)
141

Description

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](https://github.com/Microsoft/msbuild/issues/2803), 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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.