[BUG] NuGet: Support build metadata properly #26074
-
The repo for the following package is https://github.com/verybadcat/CSharpMath. After creating a
The important line is
Opening the URL
, this line is outputted:
This is because
is the actual URL. Contrast this with e.g. Xamarin.Forms on NuGet.org, version
, the download URL is
, which has NO build metadata in the name. Therefore, the NuGet GitHub Package registry appending the build metadata to the download URL is incompatible with existing .NET tooling and should be fixed. Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 18 comments
-
Hi @happypig375, I didn’t know NuGet supported SemVer2 and metadata! I haven’t been able to find much documentation about it. Here are a couple of blog entries and the docs was able to find: NuGet Package Version ReferenceExact details on specifying version numbers and ranges for other packages upon which a NuGet package depends, and how dependencies are installed. The NuGet Blog – 15 Aug 17 What's Nu in NuGet with Visual Studio 2017 version 15.3? | The NuGet BlogWe are happy to announce an update to the NuGet client that comes bundled with Visual Studio 2017 version 15.3 RTW and .NET Core 2.0 SDK. This release introduces support for new scenarios such as .NET Core 2.0/.NET Standard 2.0, some new features, https://articles.assembla.com/en/articles/2729137-semver2-support-for-nuget-endpoints-on-myget I’m interested to know how you’re using metadata and what problem you’re hoping to solve? Do you want to be able to push multiple build of the same version (like Maven’s SNAPSHOT versions) or are you using it to link back to the commit a package version was built from? Thanks, |
Beta Was this translation helpful? Give feedback.
-
Multiple versions only differentiable by build metadata are considered the same version. This is how SemVer works. I am using metadata to store build dates - the package commit is encoded in the prerelease section. The issue is that the GitHub Package registry is incompatible with existing .NET tooling. It should follow NuGet.org in package URL generation. |
Beta Was this translation helpful? Give feedback.
-
@happypig375 am I understanding this correctly.
It sounds like the easy fix would be to simply ignore everything after |
Beta Was this translation helpful? Give feedback.
-
jcansdale:
The metadata IS metadata, no matter the content. Just support it properly, thanks.
jcansdale:
If NuGet.org does this, then GitHub Packages should too. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I meant when the metadata isn’t specified. 😉 |
Beta Was this translation helpful? Give feedback.
-
I’m also running into this issue. You can’t even manually specify the build metadata as a workaround either since NuGet ignores it entirely. I made a quick repository that demonstrates the issue using GitHub Actions: GitHubPathogenPlayground/GitHubPackagesBuildMetadataTestRepo that uses GitHub Actions to demonstrate https://github.community/t/bug-nuget-support-build-metadata-properly/117606/3 - PathogenPlayground/GitHubPackagesBuildMetadataTest Basically it publishes two packages to GitHub Packages: One with build metadata and one without. Then in separate jobs it attempts to add those packages to a fresh console project. (With and without explicit build metadata just to show that can’t be used as a workaround.) Here’s an example run showing the failed restores. There’s also an additional workflow that demonstrates everything works as expected when NuGet.org is used instead. |
Beta Was this translation helpful? Give feedback.
-
Hi @PathogenDavid, Thanks for putting this together! I noticed your note about PathogenPlayground/GitHubPackagesBuildMetadataTest/blob/91339050bcbdef86ad9f77df235c930e7c8a42e0/.github/workflows/test.yml#L89
I’m interested to know why you think this. An upper-case owner seems work for me, see here: jcansdale-test/nuget-errorsContribute to jcansdale-test/nuget-errors development by creating an account on GitHub. |
Beta Was this translation helpful? Give feedback.
-
I’ve sent you a PR. 🙂 Configure using actions/setup-dotnet
|
Beta Was this translation helpful? Give feedback.
-
jcansdale:
No problem, hope it helps!
jcansdale:
I do remember trying ignoring that documentation and using
jcansdale:
Got it merged and looks like it’s working! I also tested it on my real GitHub Actions consumer and it’s working as well. github.com/InfectedLibraries/ClangSharp.Pathogen[CI] Eliminated make-nuget-config.py
It turns out that uppercase letters are allowed in the owner name for GitHub Packages. See discussion here: https://github.community/t/bug-nuget-support-build-metadata-properly/117606/8 |
Beta Was this translation helpful? Give feedback.
-
PathogenDavid:
Thanks for the confirmation! I’ve suggested we update our docs to reflect this. 🙂 |
Beta Was this translation helpful? Give feedback.
-
The docs have now been updated to not insist on all lowercase! 🙂 |
Beta Was this translation helpful? Give feedback.
-
@jcansdale The original bug mentioned in the top post has yet to be fixed? |
Beta Was this translation helpful? Give feedback.
-
It hasn’t I’m afraid. 🙁 A possible workaround would be to use the following when publishing to GitHub Packages:
That way you could continue to use metadata on nuget.org, but a version stripped on metadata would be published to GitHub Packages. |
Beta Was this translation helpful? Give feedback.
-
Thanks for getting the docs issues sorted out! Unfortunately that workaround didn’t seem to work for me: https://github.com/PathogenPlayground/GitHubPackagesBuildMetadataTest/runs/1004018759?check_suite_focus=true It appears that
I’ll try to find some time to dig further later, but I thought I’d at least share what I discovered in my quick test. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the heads up! Could you open an issue about this to remind me? It looks like |
Beta Was this translation helpful? Give feedback.
-
Ah, that would certainly do it! Filed an issue here: github.com/jcansdale/gprSpecifying the version when pushing doesn't work for stripping build metadata
As per our discussion here: https://github.community/t/bug-nuget-support-build-metadata-properly/117606/15 It seems gpr push "*.nupkg" --version 1.0.0 doesn't work if the package's version is 1.0.0+BuildMetadata because... |
Beta Was this translation helpful? Give feedback.
-
I’ve created a PR with a fix for this. 🤞 Please see the “How to test” section: Strip any NuGet version metadata
It should automatically strip metadata, so you don’t need to bother with the Please let me know how you get on! |
Beta Was this translation helpful? Give feedback.
-
I replied on the PR, but for the sake of discussion consistency: I can confirm that fixed my issue. Thanks for getting the workaround fixed! |
Beta Was this translation helpful? Give feedback.
@happypig375 am I understanding this correctly.
+metadata
as part of a package version (which GitHub Packages apparently does), it should also support returning the package when the metadata itsn’t metadataIt sounds like the easy fix would be to simply ignore everything after
#
in a package version. 🤔