Proget keeps mangling NuGet package version numbers!

I get the whole Semver thing, but there are hundreds of packages on PSGallery which don't conform to Semver and Proget keeps breaking them.

Take for example version 12.2.0.0 of SqlServerDsc: https://www.powershellgallery.com/packages/SqlServerDsc/12.2.0.0

When I import this package into Proget, either through a connector feed or through uploading the .nupkg file directly, the version number is mangled from 12.2.0.0 to 12.2.0.

When I install the module on a client from ProGet, the PowerShell module gets installed into C:\Program Files\WindowsPowerShell\Modules\SqlServerDsc\12.2.0 instead of C:\Program Files\WindowsPowerShell\Modules\SqlServerDsc\12.2.0.0.

As a result the version number doesn't match the package manifest, therefore PowerShell ignores it.

Why is Proget even touching the version number? How on earth do I stop it from doing so?

Product: BuildMaster
Version: 6.1.0

ben

Hello Neil,

When I download that package from the PowerShell gallery, it has the version number 12.2.0 (not 12.2.0.0 as is shown in the UI).

I'm not sure where the extra .0 is coming from.

Hi Ben,

I'm having the same issue. I've set up a powershell feed with a connector to the PSGallery. When proget queries the PSGallery it correctly sees the 4 digit version number, however as soon as a copy of the module is cached to proget or downloaded the version number is changed to 3 digits.

As Neil described above, this caused the module to be unusable on a client due to version number mismatch with the installation location.

Thanks,

John

Hi Neil,

I'm not sure if this will help you, but I've found a workaround for this issue on proget. I've turned off caching for the PSGallery connector, and gone through and removed all the incorrectly versioned packages (I had to pull them to proget first then delete them).

So far in my testing proget is now delivering packages directly from the connector with the correct version number.

John

Hi John,

Thanks – I'll have to try that.

The root of the problem seems to be anchored in the fact that inside many of the .nuget packages from PSGallery etc, the version number appears in two different places – the .psd1 file (which is what PowerShell cares about) and the .nuspec file (which is seemingly what ProGet cares about).

In many of the cases where I've had problems, it is because the .nuspec and the .psd1 version numbers do not match, e.g. one has the fourth digit in the version number whereas the other doesn't.

I've seen some success in editing the .nuspec to match the version number in the .psd1 and then uploading the updated package into ProGet manually. Not great at all.

Neil

Can you think of any behavior that ProGet can consider?

It's clear that this is a bug on Microsoft's end, and the package-authors end... and trying to work-around it doesn't seem so simple...

Hi Alana,

Yes it does seem fairly in Microsoft's court – I've raised an issue on the PowerShellGallery repository about it too. I am not yet sure if I'll get a response.

In the meantime, I am wondering which version number ProGet should respect in order to avoid the problem.

On the side of .nuspec, that seems like the initially obvious choice that this file should contain the version number of the package as a whole.

However, on the side of .psd1, that's the version that PowerShell itself actually cares about and that's the manifest file that gets checked when loading a PS module. (PowerShell doesn't even remotely care about the .nuspec file it seems.)

My feeling is that if ProGet can see an obvious difference between the two version numbers, that it should go with the longer and/or higher version number of the two which typically seems to appear in the .psd1 manifest. That way it stands a better chance of being unique, as opposed to the .nuspec which incorrectly seems to reuse shorter/less precise version numbers across multiple versions of the same package.

Neil

apxltd

Ugh, this sounds like a mess :(

Your comments on that GitHub issue seem spot on, and I'm not so keen on introducing quirky behavior to workaround their bugs. We made that mistake on the NuGet feeds and it made life worse for everyone, especially when the NuGet team silently fixed them (and introduced more weird behavior).

So I think we should just handle this via docs for now. I've updated the docs, feel free to suggestion more changes :)

seanl_4808

The root of the issue is the NuGet team's decision to force SemVer: https://github.com/NuGet/Home/issues/3050