-
Notifications
You must be signed in to change notification settings - Fork 695
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
Make PackageSpecDependencyProvider consider the version being requested #5452
Conversation
cc @ViktorHofer |
test/NuGet.Core.Tests/NuGet.Commands.Test/RestoreCommandTests/RestoreCommandTests.cs
Show resolved
Hide resolved
src/NuGet.Core/NuGet.ProjectModel/PackageSpecReferenceDependencyProvider.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if the null version range could be a breaking change?
@@ -86,7 +86,15 @@ public Library GetLibrary(LibraryRange libraryRange, NuGetFramework targetFramew | |||
// This must exist in the external references | |||
if (_externalProjectsByUniqueName.TryGetValue(name, out ExternalProjectReference externalReference)) | |||
{ | |||
packageSpec = externalReference.PackageSpec; | |||
if (externalReference.PackageSpec == null || | |||
libraryRange.VersionRange.FindBestMatch(new NuGetVersion[] { externalReference.PackageSpec.Version }) != null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VersionRange
can be null to represent "all versions".
libraryRange.VersionRange.FindBestMatch(new NuGetVersion[] { externalReference.PackageSpec.Version }) != null) | |
libraryRange.VersionRange?.FindBestMatch(new NuGetVersion[] { externalReference.PackageSpec.Version }) != null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how this should work yet.
It's pretty surprising to me that we've gotten no null refs in the tests.
test/NuGet.Core.Tests/NuGet.Commands.Test/RestoreCommandTests/RestoreCommandTests.cs
Outdated
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Commands.Test/RestoreCommandTests/RestoreCommandTests.cs
Outdated
Show resolved
Hide resolved
fb5bf29
to
41cefd7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Projects are expected to be preferred over packages, but only when the version matches
Why's that? It's not intuitive to me.
I really liked the project.json
feature, from .NET Core 1.0 pre-release days, where you could add a package's project to the build, via global.json
, and then it would use the project rather than the package. I thought it was regardless of version. This makes it much easier to debug and develop a package which has a bug in another project in a different repo.
Although perhaps this is straying too far from the linked bug and is a different feature request instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version check allows you to be able to explicitly depend on a package if you choose to.
Now it'd replace package with project every single time.
There's obviously a lot of feature options here, like for example, being able to control whether project o package replacement is allowed.
This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
@nkolev92 please re-open this PR |
Thanks for reopening @jeffkl. @ViktorHofer I'll get to this soon. |
This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
@nkolev92 we would really like to consume this bugfix in runtime as part of upgrading to a nightly 9.0 SDK / Preview 1. I don't think there's much left here, right? |
This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
Fixes: NuGet/Home#10368 Re-submit of NuGet#5452 NuGet gets confused with transitive project and package dependencies with the same identity (name) in a multi-targeting project and selects the wrong type (project instead of package). Projects are expected to be preferred over packages, but only when the version matches. If the version doesn't match, projects shouldn't be selected in frameworks which don't declare a ProjectReference to those projects.
Bug
Fixes: NuGet/Home#10368
Regression? Last working version:
Description
Replacement for #5397.
Projects are expected to be preferred over packages, but only when the version matches. Note that project version does that
NuGet.Client/src/NuGet.Core/NuGet.Commands/RestoreCommand/SourceRepositoryDependencyProvider.cs
Lines 289 to 299 in 83912bc
If this is not done, then projects may be selected in frameworks in which the project was never referenced.
More details in #5397 (comment).
Note that the test in question validates the scenario the runtime team is experiencing.
PR Checklist
PR has a meaningful title
PR has a linked issue.
Described changes
Tests
Documentation