We have a large solution (61 projects, and 178366 lines of code of c# files).
We target .net core 1.1 and .net framework 4.6.2.
It generally takes 60 seconds to execute a nuget restore command via Visual Studio 2017 Community 15.2. 
We would like it to be much less, if possible. An acceptable number would be 15 seconds tops.
Our CI server (Teamcity) uses the following command :
dotnet restore -r debian.8-x64 SolutionFile.sln . The last build took 2 min 40 s. It seems very long.
Another question that comes to mind is that on subsequent runs, the restore should be much faster because all the packages are already downloaded to our machines / our build server. Isn't there some sort of cache to prevent scanning all versions of each csproj ?
NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
VS UI and dotnet.exe
NuGet version (x.x.x.xxx):
Package Manager Console Host Version 4.2.0.2457
dotnet.exe --version (if appropriate):
1.0.4
VS version (if appropriate):
VS 2017 Community 15.2
OS version (i.e. win10 v1607 (14393.321)):
Win 10 v1703 15063.413
Have a large solution with a lot of nuget packages in each project
Execute a Nuget Restore on solution via VS user interface
See the slow performance of the nuget restore command
Alternatively : Use dotnet.exe restore file.sln --versbosity diag and see that restoring nuget packages takes a very long time, each time it is run.
Please include verbose logs (NuGet.exe 
I included the dotnet.exe restore file.sln --versbosity diag from the solution that is also included in the zip file.
I included a sample solution that is exactly the solution we use.
It won't compile, because I deleted all files from it, except the .csproj. The nuget restore works though.
A lot of work around restore performance has gone into VS 15.3 and CLI 1.1.0/2.0.0.  Take a look at the following issues:
https://github.com/NuGet/Home/issues/5080
https://github.com/NuGet/Home/issues/4592
You might also want to check how long it takes MSBuild to evaluate your project, for example compare the restore time to the time it takes msbuild /t:Clean to run. Restore needs MSBuild to evaluate the projects first before reading package references, if the projects are authored in a way this takes a long time it can slow down restore.
The problem is that VS 2017 Preview 3 (15.3) is unusable right now, it crashes and is much much slower than VS 15.2.
Here are the results of using Msbuild / Nuget restore for the same solution :
MSBuild /Version : (R) Build Engine version 15.1.1012.6693
msbuild /t:clean Solution.sln
Time Elapsed 00:00:19.68
Nuget Cli 4.3.0-preview1
nuget restore Solution.sln
command took 0:0:45.33 (45.33s total)
Nuget Cli 4.1.0
nuget restore Solution.sln
command took 0:0:44.54 (44.54s total)
So it seems that nuget still takes 20 seconds more than the MSBuild /t:clean even on a second run when there is nothing new to restore.
NuGet package restore is slow even for small solutions. With only two .NET Core projects in my solution, when the build system feels like doing a restore before compilation, it takes about two full seconds, even if nothing has changed. Considering that it only needs to check a handful of version numbers, that seems like about 1990 ms longer than it ought to take. It takes the snappiness out of builds that was so nice in the good old days of C#.
Orchard Core is 120 project and on my Surface Pro 3 i7... its like watching ice melt.... sooooo slow, and then you do something, and the whole process starts again. Id say, it takes 5-10 minutes for nuget to restore... ive tried Git Clean -fxd, wiping all nuget caches, reinstall VS....
Total agreement with @breyed - even if nothing changes it just starts again. Really hope newer versions solve these perf issues
It's faster from the command line, the big issue is VS and Nuget integration.
Sam problems here. Very slow even for a solution with 4 projects. Takes 3-5 minutes every time I update a nuget package. Running the 15.3.2 RTM version atm.
@gustyn do your projects use packages.config or PackageReference?
PackageReference it looks like only. No packages.config in my projects. Upgrading the projects from 1.1.2 which were setup under 1.1.2
nuget is 4.3 as well....but to be honest did not make any difference. I is just a slow as before 4.3
@gustyn could you share a repro project where you are seeing this? Could you also share the output log from the package manager output window?
A few more questions, do you see the same performance from the command line using msbuild /t:restore and nuget.exe?
This issue is specific to VS Community, but that has all the same code. I'm curious if the problem is actually specific to Community or if this is a general restore perf issue.
I am using VS Professional,  sorry didn't really pay any attention to this being the community forums
I have not yet tried it from the command line using msbuild and nuget yet
Here is the output window contents
Restoring packages for C:\Users\sj\Source\Repos\GPAssessments\GPAssessments\Server\API\API.Web\API.Web.csproj...
Installing NuGet package Microsoft.ApplicationInsights.AspNetCore 2.1.1.
Committing restore...
Writing lock file to disk. Path: C:\Users\sj\Source\Repos\GPAssessments\GPAssessments\Server\API\API.Web\obj\project.assets.json
Restore completed in 1.39 sec for C:\Users\sj\Source\Repos\GPAssessments\GPAssessments\Server\API\API.Web\API.Web.csproj.
Successfully uninstalled 'Microsoft.ApplicationInsights 2.2.0' from API.Web
Successfully uninstalled 'Microsoft.ApplicationInsights.AspNetCore 2.0.0' from API.Web
Successfully uninstalled 'runtime.native.System.Security.Cryptography 4.0.0' from API.Web
Successfully uninstalled 'System.Net.Http 4.1.0' from API.Web
Successfully uninstalled 'System.Net.NameResolution 4.0.0' from API.Web
Successfully uninstalled 'System.Net.Primitives 4.0.11' from API.Web
Successfully installed 'Microsoft.ApplicationInsights 2.4.0' to API.Web
Successfully installed 'Microsoft.ApplicationInsights.AspNetCore 2.1.1' to API.Web
Successfully installed 'Microsoft.ApplicationInsights.DependencyCollector 2.4.1' to API.Web
Successfully installed 'Microsoft.Extensions.PlatformAbstractions 1.1.0' to API.Web
Successfully installed 'System.Net.NameResolution 4.3.0' to API.Web
Successfully installed 'System.Net.Primitives 4.3.0' to API.Web
Executing nuget actions took 1.58 min
Time Elapsed: 00:01:36.3749001
========== Finished ==========
Restoring NuGet packages...
Time Elapsed: 00:00:01.9495766
========== Finished ==========
I think there is something more serious/basic going on here....It seems to take forever to even delete a file atm.
PackageReference projects do not uninstall packages, does API.Web.csproj contain a packages.config file?
packages.config works differently and needs to add/remove all files through VS which is much slower.
No packages.config refed in csproj file an no packages.config even when show all files is enabled
From: Justin Emgarten [mailto:[email protected]]
Sent: Wednesday, August 23, 2017 3:03 PM
To: NuGet/Home Home@noreply.github.com
Cc: Samuel sam@clanjohnson.com; Mention mention@noreply.github.com
Subject: Re: [NuGet/Home] Nuget Restore slow on VS 2017 Community 15.2 and .Net Core 1.0.4 (#5434)
PackageReference projects do not uninstall packages, does API.Web.csproj contain a packages.config file?
packages.config works differently and needs to add/remove all files through VS which is much slower.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/NuGet/Home/issues/5434#issuecomment-324432157, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AI9goXh-io6kvzGv6uf4Q11scNtP7KLvks5sbHdxgaJpZM4N8mj-.
Same here. We have solutions with 2 projects or 20+ and the restore takes 3 - 5 mins.
I did try this locally on our package server. If you restore and build on your package server the restore takes one TENTH as long or even less.
So, the best work around i can offer is to use your package server as a build agent for now until MS solves this problem more resolutely.
@Wil73 this issue is specific to the Community SKU being slower than the Enterprise SKU for the same restore scenario. Is that what you are seeing also? What version of VS are you using?
We use VS 2015 with nuget 3.5
We have tried out VS 2017 with nuget 4 and it's not much faster.
We have done extensive testing using the package server as a build server and this reduces the restore time by upwards of 90%. This does appear to be related to network traffic/load for nuget restore
Hi everyone, we've made significant performance improvements for NuGet Restore in 16.5 and 16.6, particularly for subsequent restores. Would you please try those versions out and open new issues as appropriate? Thank you for your feedback!
cc @nkolev92 @anangaur @zkat
Most helpful comment
Orchard Core is 120 project and on my Surface Pro 3 i7... its like watching ice melt.... sooooo slow, and then you do something, and the whole process starts again. Id say, it takes 5-10 minutes for nuget to restore... ive tried Git Clean -fxd, wiping all nuget caches, reinstall VS....
Total agreement with @breyed - even if nothing changes it just starts again. Really hope newer versions solve these perf issues
It's faster from the command line, the big issue is VS and Nuget integration.