Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
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 -
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
.0is 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
-
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 :)
-
The root of the issue is the NuGet team's decision to force SemVer: https://github.com/NuGet/Home/issues/3050
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login