Version 6.12 of the NuGet package manager introduced in Microsoft .NET 9 offers many advantages, but it still leads to performance problems despite the improvements. A revamped algorithm causes this.
The dependency resolver in NuGet 6.12, part of .NET 9, gives developers new capabilities. With this package manager, they can use the dotnet restore command to check all dependencies in external libraries or downloads at any time. The command checks not only for compatibility issues but also, since .NET 8, for security vulnerabilities.
Thanks to improvements in NuGet for .NET 9, package restoration can be up to fifteen times faster. This has been made possible by a revamp of the obsolete dependency graph resolution algorithm. This old algorithm, which had been used since the first version of NuGet, was considered inefficient and was originally intended as a temporary solution.
The new algorithm solved previous problems, such as extremely long processing times of 30 minutes or more—using fewer nodes reduced restore times to as little as 2 minutes in some cases.
Still problems
Despite these improvements, the updated algorithm in NuGet v6.12 appears to cause new issues. Although the dependency resolver ultimately returns the same packages as the old algorithm, it also downloads additional unused packages.
One specific problem occurs with jQuery versions. The package jQuery.Validation depends on jQuery 1.4.4, but at the same time jQuery 1.10.2 is specified. The old algorithm only used the prior version, but the new algorithm caused a conflict. This causes the restore to fail when trying to download jQuery 1.4.4, since this version is unavailable.
A workaround for this problem is configuring the RestoreUseLegacyDependencyResolver feature in the MSBuild configuration. However, this solution brings back the slower restore times of the old algorithm, whereas NuGet 6.12 was intended to speed this up.
Microsoft has not released a final fix yet, but one is likely to follow soon, as Microsoft also uses these development tools internally.