Download is slow in some countries when CDN is enabled

[JohnnyZhang0628]

Description:
Hello，I’m from china.I found download .net version from https://dotnetcli.azureedge.net/dotnet/release-metadata/releases-index.json. For example .net 6 Url is https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/6.0/releases.json

But install.sh is https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.413/dotnet-sdk-6.0.413-linux-x64.tar.gz not than https://download.visualstudio.microsoft.com/download/pr/66b8d73b-a371-4208-97f7-80b2dc55dfac/9cc37d50e7f83a0782b80ce8fbb8d935/dotnet-sdk-6.0.413-linux-musl-x64.tar.gz. I download the first url speed 20k/s,download second url speed 5M/s

Justification:

download speed in 1 minute

Are you willing to submit a PR?

[marko-zivic-93]

Hello @JohnnyZhang0628,
Thank you for letting us know about this feature request. We will investigate and come back as soon as we have some relevant feedback.

[IvanZosimov]

Hi, @JohnnyZhang0628 👋 The install.sh script downloads .NET from the https://dotnetcli.azureedge.net because it's the address of the CDN (you can read more about it here). Generally its purpose is to speed up the download. How long do you face this situation, is it a constant problem?

[JohnnyZhang0628]

Hi, @JohnnyZhang0628 👋 The install.sh script downloads .NET from the https://dotnetcli.azureedge.net because it's the address of the CDN (you can read more about it here). Generally its purpose is to speed up the download. How long do you face this situation, is it a constant problem?

@IvanZosimov Thanks reply.It's last a week.The CDN Url not apply for china.Now i try to write my script to download .net6.

[IvanZosimov]

@JohnnyZhang0628, thanks for clarification, we weren't aware about such issue. I'd keep the issue as a feature request and see if it gets more attention from other customers.

[vmal-altium]

Same situation if running from Europe for the last few weeks. Downloads can take 20+ minutes if succeeding at all, while US downloads complete in seconds.

[JohnnyZhang0628]

Same situation if running from Europe for the last few weeks. Downloads can take 20+ minutes if succeeding at all, while US downloads complete in seconds.
@vmal-altium I use this script solved the question.

wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
apt-get update  && apt-get install -y dotnet-sdk-6.0

[vmal-altium]

Well, I ended up temporarily hardcoding better IPs for the DNS resolution of the CDN address... It seems to be more of a Microsoft/Edgio issue with picking a server close by, rather than this GitHub action code (api.nuget.org shows similar issues).

[VAllens]

Just add one -AzureFeed(--azure-feed) parameter, which is already supported by dotnet-install.sh/ps1.

After the user enters this parameter, replace it.

dotnet-install.ps1: .PARAMETER AzureFeed
dotnet-install.sh: --azure-feed|-[Aa]zure[Ff]eed)

[jingliancui]

very slow in China , it take more than 1 hour and still not finishe the download! :

Performing server validations against '192.168.3.22'...
Setting up user remote session...
Selected project configuration for DotNet validation: C:\Users\ericc\Desktop\AlipaySampleApp\SampleApp\SampleApp\SampleApp.csproj: SampleApp.Debug|AnyCPU|net8.0-ios.17.2
Installing dotnet SDK '8.0.303-servicing.24317.8'...
Downloading dotnet-install script...
Using dotnet install script '/Users/ericcui/Library/Caches/Xamarin/XMA/SDKs/dotnet/scripts/dotnet-install.sh'...
--install-dir /Users/ericcui/Library/Caches/Xamarin/XMA/SDKs/dotnet --version 8.0.303-servicing.24317.8 --architecture Arm64 --no-path
dotnet-install: Attempting to download using primary link https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.303-servicing.24317.8/dotnet-sdk-8.0.303-osx-arm64.tar.gz

[xen0n]

This is also relevant for "community-supported architectures" of .NET, where Microsoft does not itself host the SDK and relevant packages, and one has to pull the SDK from an alternate location via --azure-feed. FWIW currently LoongArch, RISC-V, PPC64LE and S390X fall under this category.