Error during NuGet download when using v2 URL and repo hosted by Artifactory

[Inirit]

Note: This issue is related to #378 but not the same. It is a new issue that I foresee after a fix for #378 is released.

When using a v2 URL for the source of a package, rules_dotnet (with a fix for #378) will create a URL that conforms to the pattern "{source}/package/{id}/{version}". However, if the NuGet source is hosted by Artifactory, this URL will be invalid and you will get a 405 Method Not Allowed error. Instead, the URL would have to be of the form "{source}/Download/{id}/{version}". This poses a problem as the format of the URL appears to be hardcoded in nuget_archive.bzl.

I don't know what kind of configuration exists on the Artifactory side, maybe it's possible to configure that token in the URL to match the convention of the public NuGet URL, but this hasn't been a problem for any other NuGet client tooling including Paket.

[Inirit]

One more thing: Since Artifactory is used, it could be suggested to use a v3 URL instead to work around this problem. However, when using paket2bazel to generate the bzl file, Paket encounters an error due to a missing v3 resource type "PackageBaseAddress". This is a known Paket/Artifactory issue. However, even if this was worked around by manually creating the bzl file, I suspect rules_dotnet would still fail due to the same requirement of the missing resource type. Therefore, a v3 URL cannot be used as a workaround at this time.

[purkhusid]

I would be open to having a specific path for Artifactory repositories if it's possible to detect it. I don't use and have never used Artifactory so I think I the contribution would have to come from someone else.

[Inirit]

I'd be concerned with there being a specific code path for Artifactory, therefore opening up an unbounded surface area of custom handling for various NuGet providers. Rather, it's my assumption that a package's download URL would get derived via the API itself, e.g. https://www.nuget.org/api/v2/Packages(Id='Amazon.Lambda.Core',Version='2.1.0') returns an XML file that has the actual download URL within it. This path should be common across any NuGet provider since it's actually part of the API (though I'm having trouble finding documentation about the v2 API), whereas the download URL appears to be arbitrary.

[Inirit]

So I think I have a viable workaround for this issue. The experimental_downloader_config command line option allows you to intercept and rewrite URLs used by the Bazel downloader. With this I can set my source as the public NuGet v2 URL and then rewrite it in the format that works with our internal Artifactory instance.

Personally I'd almost consider this a complete "fix" for this issue, except for the fact that the command line option is labeled as "experimental" and I don't know what that means for long term support.

[purkhusid]

Ok, this sounds like an acceptable workaround for the time being. I'll keep the issue open so that I will remember to document this at some point