Channel 8.0 installing old version

[IvanJosipovic]

When running dotnet-install.ps1 -Channel 8.0, it installs .Net 8 Preview 6 instead of Preview 7.

Seems the issue is with, https://dotnetcli.azureedge.net/dotnet/Sdk/8.0/latest.version

.Net 8 Preview 7 was released 2 days ago, https://github.com/dotnet/sdk/releases/tag/v8.0.100-preview.7.23376.5

[baronfel]

@AR-May can you take a look at the release automation that pushes builds to these buckets tomorrow?

[IvanJosipovic]

One thing I noticed is that depending on the location, the script works, so it may be a CDN cache that needs to be purged.

[donJoseLuis]

Greetings, A local test showed the expected bits in blob storage.

.\dotnet-install.ps1 -Channel 8.0 -dryrun dotnet-install: Payload URLs: dotnet-install: URL #0 - primary: https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.100-preview.7.23376.3/dotnet-sdk-8.0.100-preview.7.23376.3-win-x64.zip dotnet-install: URL #1 - legacy: https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.100-preview.7.23376.3/dotnet-dev-win-x64.8.0.100-preview.7.23376.3.zip

The folks that maintain the processes that place bits on blob storage also confirmed the bits are there.

For sure this is not a problem with the install-scripts, because of that I'll close the issue.

@IvanJosipovic are you still experiencing the problem? If so, can you please share a network trace to understand where the problem is? A should likely be tracked by the entity that owns the network node causing the problem.

[donJoseLuis]

@IvanJosipovic I am glad you're unblocked. Seems like intermittent network issues were the culprit. Please if you experience this again (hopefully not), collect a network trace & add it to a ticket. We'll gladly investigate.

Happy developing to you!

[IvanJosipovic]

Hey, sorry I spoke to soon.

I can repro the issue with Github Actions right now.

See pipeline, https://github.com/IvanJosipovic/dotnetinstall/blob/main/.github/workflows/cicd.yaml

Subsequent run worked, feels like some CDN server hasn't updated yet.

[donJoseLuis]

Greetings @IvanJosipovic I just now noticed your comments after the issue was closed.

The best way to trouble shoot the issue would be to have a network trace when it reproduces. I agree with your conclusion that the culprit is in the network layer. A trace will specifically identify that.

can you please share the outcomes of the following...?

• tracert dotnetcli.azureedge.net
• curl --head https://dotnetcli.azureedge.net/dotnet/Sdk/8.0.100-preview.7.23376.3/dotnet-sdk-8.0.100-preview.7.23376.3-win-x64.zip [or curl --head {URL of bits you encounter problems with}]