jfrog rt dotnet restore inconsistently fails with nuget.org connection timeout

[ri-paul]

Describe the bug
Full transcript at jfrog/jfrog-cli#1011.
jfrog rt dotnet restore uses v2 protocol by default if config is not explicitly supplied. This issue can be seen in the artifactory-service logs with packages being pulled from the v2 nuget endpoint.

Contacted jfrog support who confirmed that v2 is unreliable, and v3 should be used.

Confirmed the using dotnet cli or nuget cli correctly uses v3 endpoint.

When configuring the temp NuGet.config file, jfrog cli omits required protocolVersion="3".

In

jfrog-cli-core/artifactory/commands/dotnet/dotnetcommand.go

Line 260 in 6367720

func (dc *DotnetCommand) InitNewConfig(configDirPath string) (configFile *os.File, err error) {

, the code builds the source url, setting v3 (default) or v2 nuget feed depending on flag. This part works well, but an additional attribute protocolVersion="3" in NuGet.config is required for a v3 feed. It isn't enough just to set the correct sourceUrl.

The difficulty here is that the native nuget cli (first branch in code below) doesn't support specifying protocolVersion. The config file has to be edited after the fact. As such it may be better to remove the 'nuget cli' branch, and inject the protocolVersion into code using a formatted string. Modifying the constant dotnet.ConfigFileFormat to explicitly include the protocol version string, then setting it to 2 or 3 depending on the dc.useNugetV2 value.

	if dc.useNugetAddSource {
		err = dc.AddNugetAuthToConfig(dc.toolchainType, configFile, sourceUrl, user, password)
	} else {
		_, err = fmt.Fprintf(configFile, dotnet.ConfigFileFormat, sourceUrl, user, password)
	}

To Reproduce
Unable to provide code to reproduce as we experience this as part of our Cloud Artifactory setup. Our configuration is:

• A local nuget repository - default configuration
• A remote nuget repository - default configuration pointing to nuget.org
• A virtual nuget repository that includes the above two repositories
• All repos set for private (auth) access

When running the following in GHA

jfrog rt dotnet-config --repo-resolve "${{ env.NUGET_JFROG_REPO }}" --server-id-resolve "${{ secrets.JFROG_SERVER }}"
jfrog rt dotnet restore $SLN_NAME

Consistently fails with the following error (although not always the same package)

Error : The feed 'JFrogCli [https://***.jfrog.io/***/api/nuget/***]' lists package 'Microsoft.AspNetCore.Hosting.2.2.7' but multiple attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress. Verify the package exists on the feed and try again. 

Artifactory Service Log shows (sample - multiple timeout exceptions present):
2021-03-16T08:26:10.648Z [jfrt ] [WARN ] [e6edd6ff677f9b80] [o.a.r.RemoteRepoBase:505 ] [p-nio-8081-exec-5788] - nuget-remote: Error in getting information for 'System.Reflection.Metadata.1.6.0.nupkg' (Failed retrieving resource from https://www.nuget.org/api/v2/package/System.Reflection.Metadata/1.6.0: Connect to globalcdn.nuget.org:443 [globalcdn.nuget.org/152.199.23.209] failed: connect timed out).

Artifactory Request Log shows 404:
2021-03-16T08:26:10.649Z|***|20.186.104.***|***-user|GET|/api/nuget/***/Download/System.Reflection.Metadata/1.6.0|404|-1|0|30842|NuGet .NET Core MSBuild Task/5.7.0 (Linux 5.4.0-1040-azure #42-Ubuntu SMP Fri Feb 5 15:39:06 UTC 2021)

Expected behavior
Artifactory Service Log should show that v3 endpoint is being consumed.
jfrog rt dotnet restore should succeed and experience no timeout issues when hitting nuget.org remote repo.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions

• JFrog CLI core version:
• JFrog CLI version (if applicable):
• Artifactory version:

Additional context

• JFrog CLI version: 1.39.7 (from jfrog/setup-jfrog-cli@v1)
• JFrog CLI operating system: Ubuntu 20.04.2 LTS
• Artifactory Version: Cloud / SaaS Artifactory

[eyalbe4]

We believe that this PR - #99 - may resolve the issue, because the v3 endpoint is more stable.
Your contribution is highly appreciated @ri-paul!