Improvements to NuGet restore<\/h3>\n
Here is how we have improved NuGet no-op restore performance over the last 5 releases of Visual Studio for large solutions (50+ projects) using PackageReference. These charts use percentiles to best demonstrate how restore ranks for the large solution population in terms such as p95, p75, and p50. In other words, the higher the percentile, the larger number of projects in a solution.<\/strong>\u00a0<\/strong><\/p>\n These improvements are not only for large solutions! They also have an impact on small to medium solutions (1-50 projects) too.<\/p>\n Additionally, we improved the performance of restore for Visual Studio solution load by grouping restores more efficiently. This leads to a drastic change in solution load performance for large solutions such as OrchardCore<\/a>(over 150 projects).<\/p>\n Finally, we have improved the performance of continuous integration scenarios such as NuGet CLI, dotnet CLI, and MSBuild where no packages have been downloaded. Over the last 5 releases of the NuGet Client tooling, restore has improved over 40% for large solutions (50+ projects).<\/p>\n As your solution scales with more projects, you may notice that your NuGet restore takes a bit longer. We will also cover other factors that can affect the performance of NuGet restore.<\/p>\n The larger your solution is, the longer your NuGet restore may take. This is because as your solution grows, so does your dependency graphs. Your project dependency graph is a graph that represents the dependencies of packages towards each other. Depending on your package management format, you may have a flat dependency graph(packages.config) or a transitive dependency graph (PackageReference).<\/p>\n The larger your package dependency graphs become, the more complex the process of correctly evaluating and resolving all your dependencies becomes.<\/p>\n You may not even know how the restore happens but depending on how NuGet restores your packages, it can have an impact to the overall performance. For the sake of classifying restore methods, we will refer to two primary categories:<\/p>\n For example, when you are using tools like Visual Studio or dotnet build, you are using NuGet implicitly when loading your solutions or building your projects.<\/p>\n There are a few different types of package sources that NuGet uses to restore your packages with. The two main categories are file-based sources<\/strong> and http-based sources<\/strong>. Hierarchical package sources\n<\/a>are faster than flat package sources. The performance among http sources can vary as well. NuGet\u2019s package installation process<\/a> prefers the most responsive sources. The number of sources may affect the performance because NuGet now must check more sources.<\/p>\n By default, PackageReference is used for .NET Core projects. .NET Framework projects support PackageReference, but currently default to packages.config. It is recommended that you migrate to PackageReference if you can.<\/a> There are many benefits to using PackageReference such as managing all your dependencies in one place, but most importantly, you get performance improvements due to the nature of how packages are maintained in a global packages folder for performant file operations.<\/p>\n You can restore your project with a concept known as a MSBuild static graph evaluation<\/a>, in which NuGet will leverage the MSBuild static graph to evaluate your project graph for restore. If you have a large solution, this may significantly improve your restore performance.<\/p>\n Learn how you can restore with MSBuild static graph evaluation.<\/a><\/p>\n We talked about a few separate ways you can improve NuGet restore performance. Let us summarize:<\/p>\n We have heard from you that one of your biggest pain points is the performance of managing your dependencies as your project gets larger such as switching between tabs, installing new packages, updating outdated packages, and uninstalling unneeded packages.<\/p>\n For the following performance improvements, we benchmarked against the OrchardCore<\/a> project which contains over 150 projects, and the operations are done on a solution-level.<\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2021\/04\/nooprestorep95.png\")
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nWhat impacts NuGet restore performance?<\/h3>\n
Solution Size<\/h4>\n
Restore Method<\/h4>\n
\n
Package Sources<\/h4>\n
Package Management Format<\/h4>\n
MSBuild Static Graph Evaluation<\/h4>\n
How do I improve NuGet restore performance?<\/h3>\n
\n
Managing Dependencies in Visual Studio<\/h2>\n
\n