Unable to Remove Bad Nuget Version from Feed

arozanski_1087

Hallo,

I've got a package issue that I'm not sure of how to solve:

I manually repackaged a nuget to try and fix a version issue because it has some semantic version problem. This fixed an old package to have a version of 1.0 and 1.0.0 in Proget. Unfortunately this causes download errors now when I use this feed because it can't truly resolve either of those packages. I've since tried to delete the package and all of its versions and run a cleanup. When I promote the package in its original form from the test feed to the main one where the errors are, it re-creates both versions of this package that I had deleted and restores both of their statistics. I'd like to remove the bad version but it doesn't go away, even if I only delete the one I repackaged myself.

How can I get rid of it? I'm on version 5.3.17 (build 19).

atripp

Hi @arozanski_1087 ,

Can you navigate to the package(s) from the UI? If so, you should be able to delete it from the UI.... what errors are you seeing when you try to delete?

If you have a package with a quirky version, the best bet is to download it, edit the nuspec file in the package, delete the quicky package on the server, then republish it.

Best,

Alana

arozanski_1087

@atripp

What you've asked is how I've been deleting it. I go into the UI, I see the bad package version, and then delete it. I don't check "delete all versions" because it would wipe the good one. When I do delete it, I am re-directed to the main page for the feed. Once I do this, I search for the package, and I still see it there in the UI as if nothing has happened.

Of course, all versions go away when i delete all versions of the package.... that is until I promote from another feed; then they return.

atripp

@arozanski_1087 thanks for clarifying...

This will be a bit tricky to debug; there are some supported scenarios for the quirky version in the UI, but most many over the API don't work (because API requires semver).

There could be other factors at play like connectors or caching, or who knows... so could you set up a basic reproduction case, that you could share/ send to us?

create two basic packages (no contents just the nuspec file is ok) for 1.0 and 1.0.0, basically that mimic your real packages; your real packages are okay too, but in case you can't share for propietary reason
create a new NuGet feed
try to repdouce on the new NuGet feed

We've tried the above test, but don't experience the problem you describe... the packages can be deleted.

arozanski_1087

This is strangely not repeatable for me either.

I made a package on a new feed I named TestFeed, and created a nuget package called TestyMcBadVersion, gave it the semver of 1.0, and it uploads as 1.0.0 on the system. It was a completely empty package and I created it via CLI using the latest nuget.exe. I tried repackaging and deleting like we had reviewed above and... nothing. It works as intended. This was supposed to mimic the problems I was having with an older package. The official name of the package in question is Owin (I've had troubles with this in the past). the official Nuspec for it lists it as 1.0, in Proget it's listed as 1.0 because the software doesn't try to auto-fix it.

The problem seems relegated to my main feed where most of my developers pull from.

atripp

@arozanski_1087 ah, yes. Owin. It's most definitely a problem package

https://www.nuget.org/packages/Owin

There's not much we can do about this, when you have a connector to NuGet.org on the same feed. The reason is this.

Depending on which NuGet.org API call you use (v2, v2+Semver, v3), the package will be reported from NuGet.org as either 1.0 or 1.0.0.
Depending on which NuGet Client you use, and in which context, will first request "1.0.0", then request "1.0" if that fails. Or it might do it in the reverse order, depending on what's in dependency file.
The .nuspec is 1.0, as you noticed

NuGet stopped supporting this back in 2016, but unfortunately... the developers are using an 8+ year old package.

If you don't use a NuGet.org connector on the feed, you can simply follow those manual repackaging steps I mentioned, and create your own Owin 1.0.0. The clients will still be able to get it, but may issue a 1.0 request first.

arozanski_1087

@atripp I might have to go with trying a connector for this package. I got into this whole mess because I was unable to restore Owin at all after I had it in my feed after an update. I tried re-packaging it via the UI from within proget to calling it 1.0.0. This only made a package that we couldn't properly download or restore because other things depending on it were busted.

atripp

@arozanski_1087 I don't think repackaging in the UI is the best for this in theory it should work, but we we never designed or tested it for this scenario; it's more to change pre-release versions.

In theory having both versions (1.0, 1.0.0) in the feed should work; I would just delete all versions, then upload from disk, then edit the file on disk (1.0 to 1.0.0), then upload the other.

We heard of one other user doing that.

If you can find "the trick" please do share, because certainly you won't be the last person using this ancient, broken package ;)

arozanski_1087

@atripp You bet. I'll see what I can do and let you know