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

[nblumhardt]

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

[nblumhardt]

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]

Done

[cpoliver]

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]

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 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.