Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New dependency resolver downloads more packages than before #13943

Open
jeffkl opened this issue Nov 19, 2024 · 3 comments
Open

New dependency resolver downloads more packages than before #13943

jeffkl opened this issue Nov 19, 2024 · 3 comments
Assignees
Labels
Area:NewDependencyResolver Issues related to the new dependency graph resolver Priority:2 Issues for the current backlog. Type:DCR Design Change Request

Comments

@jeffkl
Copy link
Contributor

jeffkl commented Nov 19, 2024

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

@mikejohnstonPremierinc
Copy link

mikejohnstonPremierinc commented Nov 26, 2024

@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>
  1. 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
Copy link
Contributor Author

jeffkl commented Nov 26, 2024

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

@mikejohnstonPremierinc
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:NewDependencyResolver Issues related to the new dependency graph resolver Priority:2 Issues for the current backlog. Type:DCR Design Change Request
Projects
None yet
Development

No branches or pull requests

2 participants