Home: Snupkg(symbols packages) auto push alongside the main package

[Pzixel]

Details about Problem

NuGet product used: dotnet.exe

NuGet version (5.0.0):

dotnet.exe --version: 2.1.602

VS version: 16.0.1

OS version: win10 v1809 (17763.437)

Detailed repro steps so we can see the same problem

1. Create a project with

  <PropertyGroup>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  </PropertyGroup>

1. cd %SolutionRoot%
2. Run dotnet pack ProjectName --configuration=Release --include-symbols --output nupkgs
3. Run dotnet nuget push ProjectName/nupkgs/*.nupkg -k $NUGETAPIKEY -s https://www.nuget.org

Expected results:

symbols gets pushed to the nuget server

Actual result:

snuget file gets created, but it's not pushed to the server.

Verbose explanation:

If you try to push nuget package with symbols via relative path without having current working directory the same as where files sits then symbols don't get discovered and pushed to the server.

I suspect that "snuget discrovery" works in current working directory instead of looking around the file.

P.S. It didn't work even when I explicitely called dotnet nuget push ProjectName/nupkgs/*.snupkg -k $NUGETAPIKEY -s https://www.nuget.org manually

[nkolev92]

NuGet has not been auto pushing symbols/snupkg packages since https://github.com/NuGet/Home/issues/6113.

Maybe it's appropriate to reevaluate that decision now.
/cc @anangaur

[Pzixel]

Hmm, documentations says it does:

You can also push both primary and symbol packages at the same time using the below command. Both .nupkg and .snupkg files need to be present in the current folder.
nuget push MyPackage.nupkg
https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg

Anyway, it didn't work even when I expliticely did dotnet push my/path/to/MyPackage.snupkg.

Maybe I need dotnet 2.2 to make it work. Gonna test it out.

[nkolev92]

I don't think those docs are correct.

@loic-sharma, @cristinamanum, @karann-msft

I see you've made changes to those docs. To my knowledge, NuGet never auto-pushed snupkgs.
do I have the wrong impression?

[anangaur]

My understanding is that we started to auto-push with snupkg. I will check this out in a while.

@Pzixel, did you try dotnet nuget push?

[Pzixel]

@anangaur yes, that's what I did.

Here is an actual config: https://github.com/Pzixel/Solidity.Roslyn/blob/4b90ba4440be4559743260124de0bdf44c722f32/.circleci/config.yml#L24-L41

I hardcoded versions to make sure it's not because of some placeholder in the path.

[anangaur]

@Pzixel Thanks for reporting. Will take a look. I haven't been able to be on top of snupkg experiences recently - something I plan to work on, this week.

I have a feeling that in this case, the source might be incorrect. @cristinamanum, can you confirm?

command: dotnet nuget push Solidity.Roslyn/nupkgs/Solidity.Roslyn.0.1.15.snupkg -k $NUGETAPIKEY-s https://www.nuget.org

[loic-sharma]

@Pzixel, Thanks for reporting this! You can fix this by changing your source from https://www.nuget.org to https://api.nuget.org/v3/index.json. The issue is that you're using the old V2 service index, but the symbol upload API was added to the V3 APIs.

Here are what we can do to improve this situation:

1. We should update this documentation and make it clear you need to use the V3 service index https://api.nuget.org/v3/index.json.
2. We could add a hack to the NuGet client so that it uses nuget.org's V3 service index when it is given nuget.org's V2 index. This would give consumers many benefits transparently (repository signing protection + symbol uploads + better reliability and performance) and would reduce nuget.org's V2 usage dramatically (~20% of V2 usage are NuGet clients that support V3). I don't understand the full implications of such a change, so please let me know if this is a silly idea @nkolev92 @anangaur 😄

[Pzixel]

That's weird

!/bin/bash -eo pipefail

dotnet nuget push Solidity.Roslyn.Core/nupkgs/.nupkg -k $NUGETAPIKEY -s https://api.nuget.org/v3/index.json
info : Pushing Solidity.Roslyn.Core.0.1.17.nupkg to 'https://www.nuget.org/api/v2/package'...
info : PUT https://www.nuget.org/api/v2/package/
info : Created https://www.nuget.org/api/v2/package/ 659ms
info : Your package was pushed.
info : Pushing Solidity.Roslyn.Core.0.1.17.snupkg to 'https://www.nuget.org/api/v2/symbolpackage'...
info : PUT https://www.nuget.org/api/v2/symbolpackage/
info : Created https://www.nuget.org/api/v2/symbolpackage/ 202ms
info : Your package was pushed.
dotnet nuget push Solidity.Roslyn.Core/nupkgs/.snupkg -k $NUGETAPIKEY -s https://api.nuget.org/v3/index.json
info : Pushing Solidity.Roslyn.Core.0.1.17.snupkg to 'https://www.nuget.org/api/v2/symbolpackage'...
info : PUT https://www.nuget.org/api/v2/symbolpackage/
info : Conflict https://www.nuget.org/api/v2/symbolpackage/ 477ms
error: Response status code does not indicate success: 409 (It looks like there is another copy of this symbols package pending validation(s). Please wait for the validation(s) to finish before trying to replace the symbols package.).
Exited with code 1

It looks like it indeed has a discovery.

[erickson71]

I am trying to understand the impact of this bug
Are you saying that symbols are not supported when using our own artifact directory here? https://pkgs.dev.azure.com/OurOwnCustomDirectory/nuget/v2/
How might I push package with symbols here? Not having symbol support for libraries is a serious issue for us

[moses70]

To clarify:
nuget.exe (and dotnet push) is only able to push symbol packages when the API endpoint supports this!
This is the case for nuget.org, but not virtually all other nuget server I know.

To check this, please looks at the json output from : https://api.nuget.org/v3/index.json
It contains:
{
"@id": "https://www.nuget.org/api/v2/symbolpackage",
"@type": "SymbolPackagePublish/4.9.0",
"comment": "The gallery symbol publish endpoint."
},

Azure devops does not have this. And also github does not provide it. See: https://nuget.pkg.github.com/v3/index.json

Looking at this thread, this seems to cause a lot of confusion. Nuget.exe could improve this a lot if it had a warning which informs the user that it cannot push the existing .snuget package because the server's API cannot consume it.

Where can I vote or help? :-)