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

Packages are not overwritten when already present in the built-in feed #858

Closed
nblumhardt opened this Issue Apr 14, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@nblumhardt
Contributor

nblumhardt commented Apr 14, 2014

Reported via the forum; it appears overwriting a package may leave the old version rather than replacing it with a newer one.

@nblumhardt nblumhardt added this to the 2.4 milestone Apr 14, 2014

@nblumhardt nblumhardt added the bug label Apr 14, 2014

@nblumhardt

This comment has been minimized.

Contributor

nblumhardt commented Apr 29, 2014

Checked the NuGet.Lucene sources for clues; it seems the package file will be overwritten and the index entry updated, however it relies on there being no read locks open on the package file. Uncertain if this is likely to cause issues in reality.

To make absolutely certain we replace files when requested, let's remove existing matches first. At worst, the subsequent add might fail and no version be left remaining, however since the package required replacement the existing version is probably unwanted anyway.

@nblumhardt

This comment has been minimized.

Contributor

nblumhardt commented Apr 29, 2014

Done

@nblumhardt nblumhardt closed this Apr 29, 2014

@nblumhardt nblumhardt modified the milestones: 2.4.2, 2.4 Apr 30, 2014

@cpoliver

This comment has been minimized.

cpoliver commented Jul 18, 2014

If you have an a step in your automated build to publish the octopack every time the build runs - is there a way of ignoring the push if the package version is the same?

There are circumstances where the assembly version of the projects to deploy will be the same, so the existing package can be used. But pushing the same version causes nuget to error, breaking the build.

@nblumhardt

This comment has been minimized.

Contributor

nblumhardt commented Jul 21, 2014

Hi @cpoliver - no, not at present. Is it possible to use the same logic that determines whether to increment the number, to decide whether or not to publish the package? Cheers!

@lock

This comment has been minimized.

lock bot commented Nov 28, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 28, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.