Uploading snupkg using NuGet client

john.selkirk

Hi,

I am trying to upload a symbol package (snupkg) to ProGet using the NuGet client and it fails.

Has anyone had any success in doing this? It seems to just silently fail.

I debugged the NuGet client and it looks like it's trying to find a SymbolPackagePublish endpoint that does not exist.

Any hints/tips would be appreciated!

Thanks,
John.

Dan_Woolf

Hi @john-selkirk,

What version of ProGet are you using? Also, is it running on Windows or Linux/Docker?

Thanks,
Dan

alansbraga_8192

I'm having the same issue.
I'm using docker on Windows , image: proget.inedo.com/productimages/inedo/proget:latest

dotnet nuget push .\MyPackage.snupkg -k "<mykey>" --source http://localhost/nuget/meulocalsymbols

As @john-selkirk said it just silently fail.

If I try to send both at the same time, only de nupkg is sent.

dotnet nuget push .\MyPackage.nupkg -k "<mykey>" --source http://localhost/nuget/meulocal --symbol-source http://localhost/nuget/meulocalsymbols

I've discovered this project today, but I think that I understood the idea of having two different feeds one for package (meulocal) and one for symbols (meulocalsymbols). The first one I didn't check "Enable symbol and source server for this feed" and the second one I've checked.

Thanks in advance!

john.selkirk

@Dan_Woolf - Version is 6.0.13 running on a Windows VM.

Thanks!
John.

atripp

Hi @john-selkirk , hi @alansbraga_8192 ,

If you haven't seen it already, we've done our best to capture how to configure all this:
https://docs.inedo.com/docs/proget-feeds-nuget-symbol-and-source-server

Unfortunately its not as intuitive as we'd like. In general, we recommend doing the "embedded" approach for symbols, to keep things simplified.

The dotnet nuget push command has a few bugs with regards to symbol packages and ignoring the symbol-source argument. Unfortunately this is beyond our control, as it's maintained by Microsoft.

If you run a tool like Fiddler, you can clearly see it's not even trying to PUT the package. Other times it will try to push it to symbols.nuget.org, but silently fail.

nuget.exe seems to be more reliable, but you can also just use curl.exe or PowerShell to PUT the package using the NuGet API

PUT https://proget.local/nuget/feed-name/package

Cheers,
Alana

john.selkirk

Hi @atripp,

That's what I am seeing when debugging the NuGet client.

I'll post it via a powershell PUT.

Thanks!
John.

atripp

Hi @john-selkirk ,

Another customer has more details on this... it seems that newer versions of dotnet nuget silently ignores publishing symbols unless we have certain metadata in the feed index: https://github.com/NuGet/Home/issues/11871

We may have a fix for this via PG-2154, which is scheduled for July 8's maintenance release. Not sure if it will fix it, but let's hope!

In the meantime, the PUT will work fine though.

Alana

jw

In PG-2154 there is a comment "Update: this was not trivial and we will take a new approach."

Is there any update for this?

I did a quick an dirty test and to me it seemed rather easy to get it to work. I create two ProGet feeds, then downloaded the index.json from the first feed, added the SymbolPackagePublish resource to the json and pointed it to the second feed. That file was then copied on a webserver. Using its URL as a -Source for nuget.exe or putting it as defaultPushSource in the nuget.config immediately solved the problem.

If I'm not completely wrong, all that is needed is a configuration option at the first feed "Use Feed x as symbol feed" and as soon as that is configured, the index.json of the first feed can return the correct SymbolPackagePublish resource and everything should just work.

dean-houston

@lm said in Uploading snupkg using NuGet client:

If I'm not completely wrong, all that is needed is a configuration option at the first feed "Use Feed x as symbol feed" and as soon as that is configured, the index.json of the first feed can return the correct SymbolPackagePublish resource and everything should just work.

You're correct -- that would probably work, but we thought a "single feed approach" would be much better from a user-experience standpoint. This way, there's just one feed to configure, and you push package files and/or symbol files to that feed using that default NuGet configuration. The files will be are stored on disk, right next to each other.

This is something we're planning for ProGet 2023, but can probably do as a preview feature in December or January.

jw

You're correct -- that would probably work, but we thought a "single feed approach" would be much better from a user-experience standpoint. This way, there's just one feed to configure, and you push package files and/or symbol files to that feed using that default NuGet configuration. The files will be are stored on disk, right next to each other.

True, though there are also a few downsides worth mentioning. Signatures don't work anymore and the package itself is always different (Size, file hash) to what a build server might spit out, making protentional issues in the pipeline harder to spot. Once the SymbolPackagePublish resource is implemented there really is no downside for the user anymore, a single nuget push command will do.
Also another pleasant side effect to this is, that it would now be possible to manually push .snupkg to a ProGet feed with nuget.exe, because even in this case the client is checking for this resource on server side before doing anything.

This is something we're planning for ProGet 2023, but can probably do as a preview feature in December or January.

That is good to hear, thanks.

dean-houston

@lm FYI, our plan is to create a second URL for pushing symbol packages, and then essentially save the files pushed to that URL as .snupkg, next to the .nupkg files on disk. This URL will be wired to SymbolPackagePublish and documented.

So hopefully this will make a better user experience, and then also help w/ the hash bits as well.

jw

@lm FYI, our plan is to create a second URL for pushing symbol packages, and then essentially save the files pushed to that URL as .snupkg, next to the .nupkg files on disk. This URL will be wired to SymbolPackagePublish and documented.

Do you mean like a second URL for a single feed? Would the .snupkg then also show up in the feeds search results?

I think it would be good to at least have an option to hide them from the regular package list. Also deleting them together would probably also make sense.

dean-houston

The logic is fairly simple, but in general the changes are:

when you push a file to /symbols, the symbols will be indexed and the file will be saved as .snupkg
when you request a symbol from /symbols, the .snupkg will be returned instead of the .nupkg file
when you delete a package, the .snupkg file will also be deleted

There's of course some details to work out, but with this approach, we're not treating .snupkg files as "NuGet Packages", so they won't show up in feeds.