Symbols aren't getting pushed when using -s sourceUrl

[Zaneo]

NuGet Product Used

NuGet.exe

Product Version

dev branch

Worked before?

No response

Impact

I'm unable to use this version

Repro Steps & Context

1. Build or aquire any valid with symbols A.nupkg and its corresponding A.snupkg
2. Specify a source which is not within a Nuget.Config
3. run: nuget push A.nupkg -Source <source> -ApiKey <apikey>

Expected Results:

• The nupkg and snupkg are pushed
• Authentication is requested from the user
• An error is thrown stating that the resource could not be accessed without authentication

Actual:

1. The nupkg is pushed

Verbose Logs

No response

[zivkan]

@Zaneo am I correct that the package source you're using doesn't use a URL ending with index.json? That's NuGet's convention for automatically detecting that an HTTP package source is V3 rather than V2.

[Zaneo]

I was trying to push to an NuGet server hosted in artifactory, and I was using a sub-path folder structure which did not end in index.json.

I believe there is a separate bug which prevents pushing when -SymbolSource is specified so I'm not able to use that. I will elaborate on that bug in an different thread when I have time.

[Zaneo]

Related: #12952

[zivkan]

I agree with your comment in #12952. I also think it's related to NuGet's V2/V3 handling. nuget.org only started supporting symbols years after NuGet came out. When nuget.org started supporting symbols, whoever was working in the team at the time added a symbols resource into the v3 service index, and added the appropriate magic into client to automatically detect it, but there are certainly gaps in the customer experience.

However, for this specific issue, NuGet treats source URLs ending in .json as V3 (I incorrectly said it was ending in index.json earlier). I don't have experience with Artifactory, but if it's possible to use a NuGet artifactory URL ending in index.json (or {anything}.json), then I suggest you use that. If it's not possible, then as a customer of Artifactory, I suggest you contact them to give them feedback that their implementation of NuGet's V3 feed, but not using a URL ending in .json, does not match NuGet's protocol version auto-detection, leading to bad experiences.

As you, and others, mentioned in #11871, setting the source in nuget.config, with protocolVersion="3", it works.

There are still several package sources that are implementing the V2 protocol, and it would be a breaking change for NuGet to start assuming all URLs provided are V3 sources. Well, in theory NuGet could try loading the URL as a service index, and if that fails then fall back to V2, but that that would require a lot of changes that are risky, so I don't think it would be a good idea.

I'm going to let the triage meeting have a look at this issue, but my suggestion is to close this as "works as designed". Someone working on #11871 would be valuable, whether that's you, another community member, or someone on the NuGet team once it can be prioritized over all our other work. But this issue, I believe NuGet is working as designed, just with poor error messages/feedback. Unless triage thinks we should use this issue to track improvements to the messages, so that customers can more easily self-diagnose the problem, before #11871 is fixed?

[Zaneo]

If this is marked as design then the code that creates a PackageSource should be removed as that will always fail to get the V3 resources as a V2 repo is always created if the source cannot be found in the loaded package source.

Even if you specify a source ending in .json, the created package source will be V2 and the code to get the V3 will exit early after reading the ProtocolVersion field.

The flow will then be, if the specified source matches an already loaded source use that to attempt to get the V3 resource, otherwise no attempt is made to load the resource. This will only be V3 if protocolVersion="3" is set in a NuGet.config that was loaded.