Rethink distribution mechanisms for known public releases

[YuliiaKovalova]

This tool has two primary usage modes:

• acquire binaries for one of the publically-available releases
• acquire binaries for a very specific version (e.g. nightlies) from a customizable location

For both cases we construct a URL with a particular layout based on the request parameters, and this URL redirects to a location with the binaries to download. The location we've stored these binaries has a few known issues, specifically for users with certain network configurations.

I propose that for the first use case, "download the latest 8.0 SDK for the Linux platform, x64 architecture", we should download the binaries from the .NET Release Manifest that the release team publishes for each monthly release.

These manifests support

• detecting support status of a 'channel' - for example in the following JSON we can see that the 8.0 channel is currently considered in 'active' status, and that it is an lts release:

{
            "channel-version": "8.0",
            "latest-release": "8.0.4",
            "latest-release-date": "2024-04-09",
            "security": true,
            "latest-runtime": "8.0.4",
            "latest-sdk": "8.0.204",
            "product": ".NET",
            "release-type" : "lts",
            "support-phase": "active",
            "eol-date": "2026-11-10",
            "releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/releases.json"
}

• discovering the latest release for a channel - for example in the above JSON the releases.json property provides a URL that links to the releases for that version. If we follow that URL, we get another manifest full of entries like this:

Here we can see clearly that we can find the list of assets by filtering on the desired .NET RID. Once we have that release we can easily get

• a download url that uses centralized download.visualstudio.microsoft.com links, which are more battle-tested
• a hash that we can use to validate the download is correct

We should only use this file when

• The user hasn't specified a custom -AzureFeed
• The user requests an SDK/Runtime/Asp.Net Runtime via the --channel and/or --quality options
  • The LTS/STS channels do not use quality, and should map to the latest 'stable' release of that kind in the release index
  • If --quality is daily then the release manifest cannot be used and the Azure Feed should be used