You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
This tool has two primary usage modes:
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
lts
release: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
We should only use this file when
-AzureFeed
--channel
and/or--quality
options--quality
is daily then the release manifest cannot be used and the Azure Feed should be usedThe text was updated successfully, but these errors were encountered: