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

PackageDownload version range implementation #7709

Open
nkolev92 opened this issue Jan 18, 2019 · 4 comments
Open

PackageDownload version range implementation #7709

nkolev92 opened this issue Jan 18, 2019 · 4 comments

Comments

@nkolev92
Copy link
Member

nkolev92 commented Jan 18, 2019

There are some considerations here:

  • How will the user know that which version got resolved.
  • Especially with the potential for duplicate IDs.
  • Make sure that the bumped up version warnings are reported.

Note: Search for TODO https://github.com/NuGet/Home/issues/7709 in the code when implementing.

Related to #7339

@nkolev92 nkolev92 added this to the Backlog milestone Jan 18, 2019
@nkolev92 nkolev92 added Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Functionality:Restore labels Jan 18, 2019
@nkolev92 nkolev92 modified the milestones: Backlog, 5.1 Jan 31, 2019
@rrelyea rrelyea modified the milestones: 5.1, 5.2 Apr 30, 2019
@nkolev92 nkolev92 modified the milestones: 5.2, Backlog Jul 1, 2019
@nkolev92
Copy link
Member Author

nkolev92 commented Jul 1, 2019

We might need this in 3.1, but there's no exact plans yet.

@scottdallamura
Copy link

scottdallamura commented Dec 22, 2020

this would be really nice to have.

scenario:
we are implementing Microsoft.DoNet.ApiCompat checks and to make it super smooth we want to reference the previously-published version of our package. with <PackageDownload> we can do that without any dependency cycles... however since it requires an explicit version, this would require us to manually edit the csproj after each publish with the newly-published version, so it keeps an error-prone human element in the process.

currently we are generating a second "OurLibrary.Baseline" package (to avoid cycles) and using that as the "contract" for ApiCompat

<PackageReference Include="OurLibrary.Baseline" Version="1.*"  GeneratePathProperty="true" />

@nkolev92 nkolev92 added Priority:2 Issues for the current backlog. and removed Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. labels Dec 2, 2021
@ericstj
Copy link

ericstj commented May 6, 2022

The lack of this feature leads to gaps in the package Validation experience see dotnet/sdk#25268. It would be nice to have this as it would help us fill a gap that users are hacking around at the moment.

@Nirmal4G
Copy link

Nirmal4G commented Oct 8, 2022

It seems to me, people were using PackageDownload items just like PackageReference except the consuming assets part. The team could have just either copy/paste the PackageReference code up until the download part or conditioned the consuming asset's part and be done with it.

This could've been a one-time thing and they could've focused their efforts on other issues that need fresh implementation.

But I did foresee this and I did exactly that, though not perfect it still works. As I said here #11720 (comment) I'll be happy if the team also updates the PackageDownload feature with #8476. Then, I can delete my custom/duplicated code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants