The latest released version of .NET desktop runtime is being reported as 9.0.0-rc.2.24474.4 instead of 9.0.0

[remco1271]

https://dotnetcli.blob.core.windows.net/dotnet/WindowsDesktop/9.0/latest.version URL is returning 9.0.0-rc.2.24474.4 instead of 9.0.0
Same as #548 but different URL.

[JanProvaznik]

@rbhanda
Please also check 8.0 & LTS

[remco1271]

ASP runtime looks good: 9.0.0 https://dotnetcli.blob.core.windows.net/dotnet/aspnetcore/Runtime/9.0/latest.version

[timlajaunie]

"LTS" and "8.0" channels for the desktop runtime are currently reporting 8.0.8, when the latest is actually 8.0.11. It seems the desktop runtime version began to lag all together at some point.

[Sewer56]

Here's the current API results formatted as a table:

Architecture	Format	Download URL
AMD64	Archive	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-x64.zip
AMD64	Executable	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-x64.exe
x86	Archive	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-x86.zip
x86	Executable	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-x86.exe
ARM	Archive	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-arm.zip
ARM	Executable	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-arm.exe
ARM64	Archive	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-arm64.zip
ARM64	Executable	https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0-rc.2.24474.4/windowsdesktop-runtime-9.0.0-rc.2.24474.4-win-arm64.exe

This happened last year too:

• Azure Endpoint for .NET 8 WindowsDesktop Runtime Points to Outdated Version #395

I reported it back then; as it wasn't resolved over a week post release (same as now).
In that case, it was resolved by @ YuliiaKovalova (avoiding a ping here) at the time.

[JanProvaznik]

@Sewer56 Where are you getting the link to these RC2 files? Is it through install scripts?
I see that https://dotnetcli.blob.core.windows.net/dotnet/WindowsDesktop/9.0/latest.version still points to a wrong version but the install scripts construct the correct version when installing.
E.g. dotnet-install.ps1' -Channel 9.0 -Runtime windowsdesktop -Architecture arm64 -Verbose

VERBOSE: dotnet-install: Retrieving primary payload URL from aka.ms link for channel: '9.0', quality: '' product: 'windowsdesktop-runtime', os: 'win', architecture: 'arm64'.
VERBOSE: dotnet-install: Constructed aka.ms link: 'https://aka.ms/dotnet/9.0/windowsdesktop-runtime-win-arm64.zip'.
...
Location: https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/9.0.0/windowsdesktop-runtime-9.0.0-win-arm64.zip

Same for LTS, STS, 8.0

We're looking into resolving the azure endpoint issue.

[Sewer56]

@JanProvaznik I'm querying latest.version endpoint, like the older versions of the dotnet-runtime scripts used to do when you request a major.minor tuple, e.g. 9.0.

Current iteration of that code in install-scripts:

install-scripts/src/dotnet-install.ps1

Line 504 in 68aa8cb

function Get-Version-From-LatestVersion-File([string]$AzureFeed, [string]$Channel) {

My C# port from a while back:

• https://github.com/Sewer56/NetCoreInstallChecker/blob/a03a420f46ad632246b5eb4c9bb9af57ddfbbff2/NetCoreInstallChecker/NetCoreInstallChecker/FrameworkDownloader.cs#L111-L129

In my case, I wrote a library for querying and downloading .NET Runtimes (since nothing like this existed at the time).

I use it in an installer; essentially I download one of my FOSS programs, parse the runtimeconfig.json file, and use the latest.version endpoint to get the latest patch for the major.minor combination. This means I can avoid install the most up to date runtime on an end user machine (in major.minor band) if they are missing it.

However, due to latest.version being out of sync, the end users are winding up installing RC2, if using the latest.version endpoint.

[timlajaunie]

Things appear to have gotten worse.

• The 9.0 Latest Version Link is now causing a "latest.version" file to be downloaded. The version within is "9.0.0", which is correct.

• The 8.0 Latest Version Link also causes a "latest.version" file to be downloaded. That file has "8.0.404" within, which is an SDK version. It should be 8.0.11.

The "/dotnet/Runtime/[9.0|8.0]/latest.version" and "/dotnet/aspnetcore/Runtime/[9.0|8.0]/latest.version" variants still work fine.

[JanProvaznik]

The file downloading issue has been resolved and everything updated. Note that you might need to go to private mode to check because the browsers cache the results.

https://dotnetcli.blob.core.windows.net/dotnet/WindowsDesktop/9.0/latest.version
https://dotnetcli.blob.core.windows.net/dotnet/WindowsDesktop/8.0/latest.version
https://dotnetcli.blob.core.windows.net/dotnet/WindowsDesktop/LTS/latest.version
https://dotnetcli.blob.core.windows.net/dotnet/WindowsDesktop/STS/latest.version

[Sewer56]

Looks good to me.