[Bug]: dotnet nuget push symbols not working as expected

[jmecosta]

NuGet Product Used

dotnet.exe

Product Version

6.0.300

Worked before?

No response

Impact

No response

Repro Steps & Context

Hi,

Ive raised a ticket on our nuget server provider (proget) and they said that "dotnet nuget push" is a "bit" buggy with when using "*" argument... Wanted to report this buggy behaviour here so can help them also clarify a bit the behaviour:

dotnet nuget push --source http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/v3/index.json *.nupkg --symbol-source http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget-symbols/v3/index.json --api-key KEY --symbol-api-key OTHERKEY --skip-duplicate

this pushes only the .nupkg Pushing TeklaFusion.4.0.4.nupkg to 'http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/package'... PUT http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/package/ Created http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/package/ 263ms Your package was pushed.

The TeklaFusion.4.0.4.snupkg is never published or even detect looks like it by the CLI tooling....

thanks in advance for the clarification jorge costa

Ive originally raise ticket on dotnet side, https://github.com/dotnet/sdk/issues/25958 but they closed it .

Verbose Logs

No response

[zivkan]

@jmecosta I was able to reproduce the issue using the same command line you used (changing the URLs to the localhost server I was testing with).

I found that by not specifying the --symbol-source <url> parameter, it actually worked. The server I was using, like nuget.org, includes a SymbolPackagePublish resource. If Proget's service index (index.json) includes this resource, just like nuget.org's does, then you should not need to specify the symbol source URL on the command line.

But we should not be silently ignoring the symbols package or silently failing, so that needs to be fixed.

[jmecosta]

@zivkan thanks for confirming the problem

[jmecosta]

@zivkan maybe related but: https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg

dotnet nuget push TeklaFusion.4.0.4.snupkg --source http://ts-nuget.teklaad.tekla.com/nuget/ts-nuget/v3/index.json

also doest do anything. i supose the SymbolPackagePublish is also missing from that source

[zivkan]

@jmecosta I just remembered that there have been some changes to push over the last 2 years:

• https://github.com/NuGet/NuGet.Client/commit/fa9fbcb87b8ce717d7f78d494cd16cf174be48e9 Added in NuGet 5.9
• https://github.com/NuGet/NuGet.Client/commit/775ebbcff4d585cb9e75608d41d711bb306e0e24 Added in NuGet 6.2

If you're on Windows, it would be great if you could try downloading NuGet.exe versions 5.8 and 6.1 from https://nuget.org/downloads, and try them out (perhaps with the --symbol-source argument), and let us know if either (or both) of those work. If this used to work and we can narrow down when it broke, it might be easier to fix.

[jmecosta]

6.2.1.2 not working 5.8.1 not working either 5.9.2 not working either

[jwfx]

Just tested this with the current dev branch (6.5) and it is not working either.

@zivkan I don't really think the code you linked could actually work.

This loop here expects a path for every package, one for .nupkg and one for .snupkg. But the command handler calling this method only allows for a single argument to pass through.

But given that .snupkg should be handled automatically without the user explicitly specifying it as an argument, there probably should be some code in between those methods that handles looking for .snupkg next to the supplied .nupkg.

Could you give an update about this issue?

[zivkan]

@jwfx we prioritize work based on a number of factors, one of which is upvotes. This issue doesn't have any upvotes yet, so might not have caught the eye of people triaging issues during sprint planning. This issue was created when it was my turn on the support rotation, and I just validated that the issue can be reproduced but support doesn't have enough time to bugfix.

[jwfx]

Thank you for the update and for linking that document. Hitting this issue directly from a search engine, that policy totally went past me.

[TobiasBreuer]

Just for information for anyone else hitting this from search engine: I just realized that in my case, the issue was in the missing protocolVersion attribute in the xml of the NuGet source.

To clarify - the follwoing would not work but instead only publish the package on push:

<add key="Artifactory" value="https://......./api/nuget/v3/xyz-local" />
<add key="ArtifactorySymbols" value="https://....../api/nuget/v3/xyz-local/symbols" />

However, changing the source definition to following:

<add key="Artifactory" value="https://......./api/nuget/v3/xyz-local" protocolVersion="3" />
<add key="ArtifactorySymbols" value="https://....../api/nuget/v3/xyz-local/symbols" />

Magically makes everything work as expected - i.e. a simple nuget push myPackage.nupkg will now push the package and detect and push the corresponding *.snupkg file.

❗ However - due to #9170 still being open, we now have to manually fix the config file as part of our CI pipeline 😞

[jwfx]

@jmecosta The just released ProGet version 2022.20 adds support for pushing .snupkg automatically together with .nupkg without using the --symbol-source parameter.

The unexpected behavior of the --symbol-source parameter in nuget.exe remains though.

[mbxsuite]

can confirm for local pushes

dotnet nuget push a.0.01.nupkg a.0.01.snupkg --source /nuget --symbol-source /snupkg

does

• only push nupgk,
• but not the new symbols package,
• state that the snupkg file does not exist, which is wrong.

Leaving out the symbol-source parameter, will lead to havinig the snupkg being silently ignored.

dotnet --version

6.0.406

dotnet nuget --version

NuGet Command Line 6.3.2.9

[jvmlet]

Same issue with nuget 6.6.1.2, please prioritize.

[jvmlet]

Just noticed that I'm getting file does not exist only in unix, executing same command on windows (dotnet nuget push My.snupckg) DOES pushes it .

[Zaneo]

Looking here: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Commands/Utility/CommandRunnerUtility.cs#L107-L110

I found when stepping through with a debugger:

if (packageSource == null)
{
    packageSource = new PackageSource(source);
}

Should probably be:

if (packageSource == null)
{
    packageSource = new PackageSource(source)
    {
        ProtocolVersion = 3
    };
}

This seems to cause the SymbolPackageUpdateResourceV3 to fail to resolve given that it creates a V2 repository by default.

[Zaneo]

I also cannot find an execution path that sets: symbolPackageUpdateResource to a non-null value if a user specifes the symbolSource

 if (string.IsNullOrEmpty(symbolSource)
                && !noSymbols
                && !sourceUri.IsFile
                && sourceUri.IsAbsoluteUri)
            {
                symbolPackageUpdateResource = await CommandRunnerUtility.GetSymbolPackageUpdateResource(sourceProvider, source);
                if (symbolPackageUpdateResource != null)
                {
                    symbolSource = symbolPackageUpdateResource.SourceUri.AbsoluteUri;
                }
            }

After this point symbolPackageUpdateResource is never assigned to.

Which causes:

bool isSymbolEndpointSnupkgCapable = symbolPackageUpdateResource != null;

To always be false.

I suspect somewhere in here:

// Precedence for symbol package API key: -SymbolApiKey param, config, package API key (Only for symbol source from SymbolPackagePublish service)
            if (!string.IsNullOrEmpty(symbolSource))
            {
                symbolApiKey ??= CommandRunnerUtility.GetApiKey(settings, symbolSource, symbolSource);

                // Only allow falling back to API key when the symbol source was obtained from SymbolPackagePublish service
                if (symbolPackageUpdateResource != null)
                {
                    symbolApiKey ??= apiKey;
                }
            }

The symbolPackageUpdateResource was supposed to be resolved.

[Zaneo]

What worked for me:

1. Do NOT specify SymbolSource this cause a failure
2. Do create a NuGet.config with your source:

   <add key="Artifactory" value="https://......./api/nuget/v3/xyz-local" protocolVersion="3" />

3. Specify EXACTLY the same string for your source, including trailing slash or not
4. Specify the A.nupkg file exactly.

dotnet nuget push "A.nupkg" -s https://......./api/nuget/v3/xyz-local -k <YOUR API KEY>