Use new CDN for dotnet builds

[Steven (sliekens)]

The azureedge.net domain might stop working as detailed in dotnet/core#9671

Changes in this PR:

• dotnet: update the logic to determine the latest version
• dotnet and oryx: copy latest dotnet-install script from
  https://github.com/dotnet/install-scripts/blob/main/src/dotnet-install.sh
  (Normally this happens automatically by a GitHub Action, but there is a sense of urgency here, so I did it manually)

Additional context

• https://devblogs.microsoft.com/dotnet/critical-dotnet-install-links-are-changing/
• https://build5nines.com/retirement-of-azureedge-net-dns-edg-io-business-closure-and-what-you-need-to-know/

[Steven (sliekens)]

Cc Samruddhi Khandale (@samruddhikhandale) Chuck Lantz (@Chuxel) joshspicer Gaurav Saini (@gauravsaini04)

[Christof Marti (chrmarti)]

Great, thanks for the PR! Left a few questions.

[Steven (sliekens)]

Christof Marti (@chrmarti) the dotnet-install.sh script is copied from https://github.com/dotnet/install-scripts/blob/main/src/dotnet-install.sh so I'm not qualified to answer those questions but I think Matt Mitchell (@mmitche) can help.

(In any case, fixes would have to be done over there, as there is a github action to overwrite the copy in this repo with upstream changes.)

[Matt Mitchell (mmitche)]

Yeah, the install script is going to get another update soon, removing the use of the azureedge domains, at least outside of sanitization. So the script would only try to access the new domains. We're not quite sure yet when we will update old aka.ms links. Once they are updated, then we would remove the sanitization altogether.

[Christof Marti (chrmarti)]

Matt Mitchell (@mmitche) Great, this sounds like we should wait for that imminent update of the install script?

Updating the aka.ms redirects would smooth things out I guess, is there a reason to hold back on that?

[Steven (sliekens)]

Don't forget that script is updated here automatically every Sunday, e.g. see #1236

I just realized I forgot to bump the version 🤔. Not sure about the semantics of this change either. Probably not a major bump, the behavior didn't change that much and usage remains the same. On the other hand, this change could break users behind corporate firewalls where the CDN is not allowed.

[Christof Marti (chrmarti)]

Don't forget that script is updated here automatically every Sunday, e.g. see #1236

I just realized I forgot to bump the version 🤔. Not sure about the semantics of this change either. Probably not a major bump, the behavior didn't change that much and usage remains the same. On the other hand, this change could break users behind corporate firewalls where the CDN is not allowed.

Minor (or patch) might work best since that will be picked up when the devcontainer.json only specifies the major version. There is also an optional lockfile devcontainer-lock.json that pins the exact feature version and checksum and would hold the update back.

I guess we could just run the workflow you mention then (catching up on how we do this): https://github.com/devcontainers/features/actions/workflows/update-dotnet-install-script.yml

[Steven (sliekens)]

A new minor version makes the most sense to me, I'll do that. I can revert the changes to dotnet-install.sh vendor script in this PR if desired, but the changes in the dotnet-helpers.sh script are still needed, I wrote those scripts specifically for the devcontainer feature to find the latest version no matter the STS or LTS status.

[Steven (sliekens)]

I guess I should fix the failing test while I'm at it 🤔.

[Steven (sliekens)]

Christof Marti (@chrmarti) I think this work is complete now.

Final changes:

• Fixed failing scenarios which installed the latest dotnet version (now .NET 9) but then tried to run a .NET 8 project
• Added .NET 9 to one of the scenarios where multiple versions are tested all at once
• Bumped dotnet minor version
• Bumped oryx minor version

[Christof Marti (chrmarti)]

Steven (@sliekens) Looks great, thanks! We can update the script again when the original changes later this/next week. Adding Gaurav Saini (@gauravsaini04) as a second reviewer.

[Gaurav Saini (gauravsaini04)]

All the changes done, LGTM 👍🏻
Thanks Steven (@sliekens) !

[Eljo George (eljog)]

We can update the script again when the original changes later this/next week

SGTM, Gaurav Saini (@gauravsaini04) let's make a note of that followup

[Bugra Cetin (cetinbug)]

For our Azure Functions, we currently use the URL functionscdn.azureedge.net to retrieve extension bundles. However, after reviewing the issue, I noticed that there is no specific mention of the subdomain functionscdn in the migration details. Could you please clarify if this subdomain will also be migrated and, if so, to which domain?

For example, we are getting extension bundles from a url like: "https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle.Preview/$EXTENSION_BUNDLE_VERSION"