New dependency resolver downloads more packages than before

[jeffkl]

NuGet Product(s) Affected

NuGet.exe, Visual Studio Package Management UI, MSBuild.exe, dotnet.exe

Current Behavior

As an optimization, the new dependency resolver downloads packages in parallel. However, when processing the direct package references, the dependencies are also downloaded when they weren't before.

For example:

Project -> A 1.0 -> B 1.0
Project -> B 2.0

The new resolver queues up a task to download A 1.0 and B 2.0. Then it processes A 1.0 and queues up a download of B 1.0. Then it processes B 2.0 which ends up being the resolved version. However, since B 2.0 was directly referenced, NuGet does not need to technically download B 1.0.

Desired Behavior

We should process all of the direct dependencies first and then use background tasks to download children after that, ensuring that extra packages are not downloaded.

Additional Context

Some users are hitting issues since their feeds don't offer up the packages. So even though the resolved graph is identical, they experience restore failures.

Workaround

Users can workaround the issue by setting an MSBuild property in their Directory.Build.props or an environment variable:

<Project>
  <PropertyGroup>
    <RestoreUseLegacyDependencyResolver>true</RestoreUseLegacyDependencyResolver>
  </PropertyGroup>
</Project>

Related Issues

#13930
https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2301598

[mikejohnstonPremierinc]

@jeffkl

Can you please post the exact steps to take in order to invoke the legacy resolver when a user is building his project within Visual Studio? Not when the user is using msbuild. After performing the steps below, it does not invoke the legacy resolver. I verified this by looking inside the project assets file within obj folder. "restoreUseLegacyDependencyResolver": true does not get added to that file.

My steps are as follows:

1. Open the solution in VS
2. Right-click on Solution from Solution Explorer
3. Select Add>New Item.
4. Name it Directory.Build.props
5. Add the XML:

<Project>
  <PropertyGroup>
    <RestoreUseLegacyDependencyResolver>true</RestoreUseLegacyDependencyResolver>
  </PropertyGroup>
</Project>

6. Save and rebuild

Note: Whenever I used CMD and msbuild to build my solution

msbuild /t:restore /p:RestoreUseLegacyDependencyResolver=true

The legacy resolver WAS invoked. I looked inside my obj\projectassets file, and it correctly showed
"restoreUseLegacyDependencyResolver": true

[jeffkl]

Where is Directory.Build.props in relation to the project? It must be in the project's directory or any directory above that.

[mikejohnstonPremierinc]

It was not in the correct directory. I moved it to the root, and now it works. Thanks!

[brett-ed]

The new resolver has a significant variation from previous behavior. My company does not allow us to restore packages directly from nuget.org. Instead, our connections are proxied thru artifactory. Artifactories Xray product blocks download of any packages that it finds vulnerabilities with. Whenever a vulnerability is found in a package we are using such as System.Text.Json, we rely on being able to list the package in Directory.Build.props, specifying a higher, non-vulnerable version.

Previously, this ensured that even transitive dependencies on vulnerable packages would be overridden. Only the version specified in Directory.Build.props would be downloaded.

The new resolver tries to retrieve the older, vulnerable versions. Artifactory blocks them, causing dotnet restore to fail.

Im facing some critical deadlines at the moment and so my resolution was to roll back to visual studio 17.11 / .Net 8

Desired behavior.

When a package is specified in Directory.Build.props, the resolver should only retrieve that version, ignoring all other direct and transitive references to that package.