Proget Sometimes Truncates Package Version

arozanski_1087

Hello!

I ran into an issue recently with a few packages that I'd like to get more information on how to solve. I noticed that there are a few packages that have a semvar of X.0.0, and instead of showing up with that version in my server, it shows up as X.0 instead and the last 0 is removed. I'll note that all packages I upload to the server are uploaded in bulk to the drop folder I have created for the feed. The server's version is Version 5.3.17 (Build 19).

An example is Owin. The latest version as indicated on Nuget.Org is 1.0.0. I've tested the download of the file from that site manually, and it appears as Owin.1.0.0.nupkg as I'd expect. However When I upload it to my proget server, it reads as 1.0. This in turn is causing weird nuget restore issues for my build server, where the package "cannot be found" because the expected version is 1.0.0 but I only have 1.0.

There are a few other packages with a similar version, like 1.0.0, or 2.0.0, and in those cases the package versions get truncated.

See example below:

I know that you can repackage a nuget file to fix the version? but I'm not sure what exactly that does to the package itself.

What I've tried:

Manually uploading a downloaded .nupkg directly off of nuget.org after verifying that it has the correct version. From there I go to my feed and upload the file directly. It shows a truncated file version.
Imported the nuget directly from the Api. This has the most peculiar results when I try to manually import from another feed, as I occasionally have problems getting the version. If I remove the last 0 from the file version it works.

Currently I have a workaround where my build server also uses the official nuget.org api to grab the packages it needs when it can't find them on my proget server. Strangely enough It will restore from there officially with that file version.

atripp

Hello;

Long story short, the problem is that your package's nuspec file has an invalid version number (1.0); if you edit the file, and put in a proper SemVer, it will be fine. This is what repackaging does, by the way. It creates a new package with a different version number.

This is a long-standing versioning quirk with NuGet that still comes up every now and then; in the old days, you could have packages like 1.0 and 1.0.00 or even 1.000.0, and they'd all be different.

NuGet dropped support for this over five years ago, but since old packages with quirk versions remain, they did all sorts of strange work-arounds in the NuGet client. For example, you may see a file request for 1.0.0, and then 1.0.0.0, then 1 then 1.0.

This is because the NuGet API only shows a three-part SemVer anymore, but the files are still accessed by their original version number. ProGet does not do the "version dance" to find the real package file, which is why you get these errors.

We eventually dropped most support for this versioning, and basically you can just have "some" quick packages in feeds, but they won't work through connectors in most cases.

arozanski_1087

@atripp

Thank you for that information. I had suspected as much that this might be a nuget problem but did not have enough information to confirm. What do you suggest I do? Should I just repackage the nuget then to fix it? From what I've seen this is a very recent issue and it almost seems better to work around it in code (on our end)

atripp

These days, there are very few packages with quicks like this, so we recommend just repackaging (either using the feature, or manually) a local copy for caching purposes.

Owin is one of these packages unfortunately. The latest (and only) package version is 1.0 (in some cases) and 1.0.0 in others. It's also over 8 years old, so it can't be helped.

ProGet 5.2 had better support for these versions quirks using a feature called "Legacy (Quirks) Feeds", but those feeds couldn't handle SemVer queries properly, since requests like 1.0 were ambiguous (should it return 1.0 or 1.0.0, both of which are valid versions, etc), so it was a big tradeoff. They were fully removed in ProGet 5.3.

arozanski_1087

Yeah, that's a nightmare and a half and I can see why you did that.

Currently I've tried repackaging the nuget but it brings about other errors, where it restores properly but later on in compile I get build errors. Right now I'm using the legacy version/older version of the nuget URL instead of the current v3 one until they get off of that package and I can remove it from my feed. It follows the format: https://url.domain/nuget/feedName/ instead of https://url.domain/nuget/feedName/v3/index.json .