Home: Why is everything related to nuget package restore/upgrade so slow

[jainaashish]

From feedback item: https://developercommunity.visualstudio.com/content/problem/97395/why-is-everything-related-to-nuget-package-restore.html

We have a solution with 12 projects and attempting to manage nuget packages at the solution level is impossibly slow. It takes minutes everything I change tab for the Nuget tab to refresh (which it seems to do everytime, even if nothing has changed).

This is something that was supposed to be improved in Nuget 3 but is still a problem that plagues us everyday!

Internal feedback ticket# 482138

[cezarypiatek]

We've got 58 projects in our solution and update of even a single package is a total nightmare. Nuget UI is sooo slow that we are unable to use it. Updating from console takes over 10 minutes for single package. I am wasting an hour everyday trying to update two packages. It's totally unacceptable.

[chrisaut]

I have to agree with this. Was upgrading xunit today in an old solution with around 50 projects or so, half of which test so had a reference to xunit.

It took like 15 minutes with near 100% CPU. Had I not seen the log output in VS from time to time I would have thought it crashed.

It's like compiling c++ in the old days....go get a coffee, stop by your colleague to chat about the weekend and if your lucky by the time your back it's done.

I dread having to touch nuget. I just don't understand what could take so long....

[kennethx]

Couldn't agree more with posters, it's so slow watching paint dry on a wall is more fun, and faster!

[loicmorvan]

Same issue with 100 projects in a solution, it's a nightmare!
I have to wait almost one hour to update one single package.

[mihail-shishkov]

I have a private nuget server setup just for our company. We have a small number (~20) of internal nuget packages with common functionality that are shared across multiple projects. Sometimes we may change/update a nuget package 10 times for a single day. Pushing the nuget to the server takes 2 3 seconds. Then updating a solution with (~30) projects takes a lot of time and gets frustrating.

[cezarypiatek]

I observed that the issue disappeared with new csproj format. I made a simple test: I created a empty library in old csproj format and installing single package took few minutes. The same test but with new csproj project - the package was installed immediately.

[blimkemann]

@cezarypiatek I agree with that. But for old csproj files it is a total nightmare. Figures that Microsoft wants to force us all to use the shiny new stuff by not supporting what we've used for years and (at least a one time) was stable.

[tstephansen]

I know the people working on this are doing their best. I also agree that updating NuGet packages is extremely slow for me as well. I have a 34 project solution and it takes over an hour to update the packages. I'm would honestly be much happier just having some sort of progress bar telling me how long it will be until the process is complete.

[bryceamacker]

Our TFS builds were getting demolished by this slowness (we're restoring 160+ projects distributed across 12 different solutions in some situations). This work around reduced our restore time by about 10x:
1) We refactored all references to point to a 'global' package install directory (global in reference to our repo root).
2) Create a python script to scrape all package.config files in the repo (each package has one), and create a single 'master' package.config file at the repo root.
3) Do a nuget restore on that single packages.config into the global package directory.

For our particular use case (which normally spawned a new NuGet.exe restore for each project), this reduced our restore time dramatically. Unfortunately it relies on quite a bit of re-work and may not be suitable for everyone's use case.

[Zapnologica]

Also experiencing very slow nuget updates.

[kierenj]

Cripplingly slow VS NuGet UI here - what details would be best to share? .NET Core, new csproj format, ~20 projects. Installed/Updates tab sits for minutes before refreshing..

Edit: it seems to be downloading what must be hundreds of .json files for package versions from NuGet, each ~200kb. Been running for ages.

Edit: I opened and close a project file (no modifications) and it's re-started reloading all of that JSON again. That took 10-15 minutes. My god.

[jasekiw]

I disabled resharper and everything returned back to normal for me. Not sure if this will be case for others though. How can I temporary disable ReSharper

[chris-hatton]

In an age of Gigahertz-class computing; the authors of NuGet should consider the fact their software takes _several minutes_ to update a version number in a dependency tree... and do some serious soul searching. Gradle? No problem, bam, you're done in the time it takes to download the JAR. I really dread to think what's going on under NuGet's hood that takes so, so long...

[Barsonax]

The nuget 4.x libaries are also horrible to read. We tried to upgrade a packet manager for a game engine (duality) that used nuget 2.x to nuget 4.x but we ended up not doing it because getting it to work properly is almost impossible. There is also zero documentation on how to integrate it.

I don't know what they were thinking while writing nuget but the nuget team somehow managed to write code that is both horrible to read and frustratingly slow to execute.

[karann-msft]

this issue seems to be really several different issues ranging from perf for large solutions, VS UI perf, slow package updates, NuGet client upgrade experience, etc. In its current form, this issue is unfortunately not actionable.
@kierenj, @jasekiw, @chris-hatton, @Barsonax - I would request that you create separate issues for your specific scenario so that the team can triage, prioritize, and investigate.

For folks with older comments, I'd ask you to upgrade to a newer version of NuGet and retry your scenario. If you are blocked from upgrading due to any reason, or find the same issue with the newer versions, please file an appropriate issue for your scenario.

Thank you for your patience and for working with us on this.

[replaysMike]

Why is this closed? It's still a huge issue as of VS2019 (16.3.10).

[Jetski5822]

yeah - this really shouldnt be closed, the UI just keeps spinning, and when you navigate away and back to it.... the whole process starts all over again.

[silkfire]

NuGet Package Manager is still do this date one of the slowest features of VS - yet still one of the most used. Could you invest some proper development time on improving the performance of it? It doesn't make sense that it takes 20-30 sec to load the list of packages when switching tabs, and installing the packages themselves should be a smooth experience.
I'm sure developers have spent weeks in total waiting for NuGet packages to restore or for the UI to respond...

[loop-evgeny]

Still impossibly slow to in VS 16.5.4, NuGet 4.5.0.4696 to, for example, list packages on the Updates or Consolidate tab. I don't understand why this is closed? Does the NuGet team want a solution that reproduces the problem?

[SebastianJust]

I expire the same problem, when the solution has multiple projects in VS.16.5.4.
Package Manager Host version 5.5.0.6473.

[SebastianJust]

Does anybody has a work around until it, maybe, is fixed?

[RobertHenry6bev]

I have to wait 10 hours for nuget to download 1000 packages. What a terrible on boarding experience. The worst package manager I've seen in this regard.

[replaysMike]

Does anybody has a work around until it, maybe, is fixed?

Yes, don't use it. Use GrepWin and find/replace existing packages to do an upgrade, then do a dotnet restore. To add a package, edit your csproj manually. Nuget package manager is a giant pos and they don't seem to want to fix it.

[Untit1ed]

It looks like the workaround is not to use visual studio and change references manually, works faster that way on big solutions.

[smasihemami]

This is a huge headache for me working with VS 2017 15.9.25 + nuget 4.5.1.4879. It takes 15 minutes or so to update a single nuget package in a solution consisting of 140 projects. And the UI freezes meaning one cannot do anything while this process is going on. I'm really eager to know whether it's a nuget issue or a VS issue, and if there is an alternative to VS built-in nuget package manager that somehow fastens the process (ofcourse if it's not a nuget issue)

[smasihemami]

And I cannot think of a reason why this nuget update process cannot be parallelized. Looking at VS Package Manager console seems like this process takes only 1 project at a time, and yet all CPU cores are used by 100%

[aortiz-msft]

Hi everyone,

Thanks for the feedback.

We made many performance improvements in Visual Studio 2019, particularly in the last few releases (16.5, 16.6, and 16.7).

Additionally, we are tracking several potential perf improvements as part of this query: https://github.com/NuGet/Home/issues?q=is%3Aissue+label%3ATenet%3APerformance+is%3Aopen+ The following query is narrowed down to Package Manager UI improvements: https://github.com/NuGet/Home/issues?q=is%3Aissue+label%3ATenet%3APerformance+is%3Aopen+assignee%3Adonnie-msft+label%3AFunctionality%3AVisualStudioUI

Please feel free to +1 or comment in any of the issues above, or open new issues for specific scenarios you are having problems with. That would help us in providing assistance as well as in prioritizing specific scenarios.

Thanks again!

cc: @JonDouglas , @anangaur

[QTom01]

Just checking in to say in our 97 project solution it still takes 10+ minutes to install one package into one project (VS 2019 Professional latest version). God forbid when I have to update a package for all/most projects in which case it takes literally an hour+.