[main] Update dependencies from dotnet/runtime

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/runtime

• Subscription: cedddd63-79f5-4e7e-6d46-08dc434c4948
• Build: 20240530.11
• Date Produced: May 31, 2024 9:13:58 AM UTC
• Commit: 9fca0c3dbd3874ed0245b1bdb10547d0ba769d66
• Branch: refs/heads/main

• Updates:
  • Microsoft.Extensions.DependencyModel: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.Extensions.FileSystemGlobbing: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.Extensions.Logging: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.Extensions.Logging.Abstractions: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.Extensions.Logging.Console: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NET.HostModel: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NET.ILLink.Tasks: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NETCore.App.Host.win-x64: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NETCore.App.Ref: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NETCore.App.Runtime.win-x64: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NETCore.Platforms: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • System.CodeDom: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • System.Reflection.MetadataLoadContext: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • System.Resources.Extensions: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • System.Security.Cryptography.ProtectedData: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • System.ServiceProcess.ServiceController: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • System.Text.Encoding.CodePages: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • VS.Redist.Common.NetCore.SharedFramework.x64.9.0: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • VS.Redist.Common.NetCore.TargetingPack.x64.9.0: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.SourceBuild.Intermediate.runtime.linux-x64: from 9.0.0-preview.5.24272.2 to 9.0.0-preview.6.24280.11
  • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-preview.5.24264.2 to 9.0.0-preview.6.24277.2
  • Microsoft.SourceBuild.Intermediate.emsdk: from 9.0.0-preview.5.24264.2 to 9.0.0-preview.6.24277.2

Coherency Updates

The following updates ensure that dependencies with a CoherentParentDependency
attribute were produced in a build used as input to the parent dependency's build.
See Dependency Description Format

• Coherency Updates:
  • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-preview.5.24264.2 to 9.0.0-preview.6.24277.2 (parent: Microsoft.NETCore.App.Runtime.win-x64)
  • Microsoft.SourceBuild.Intermediate.emsdk: from 9.0.0-preview.5.24264.2 to 9.0.0-preview.6.24277.2 (parent: Microsoft.NETCore.App.Runtime.win-x64)

[dotnet-maestro]

Notification for subscribed users from https://github.com/dotnet/runtime:

@dotnet/dnr-codeflow

Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.

• This pull request contains changes from your source repo (https://github.com/dotnet/runtime) and seems to have failed checks in this PR. Please take a peek at the failures and comment if they seem relevant to your changes.
• If you're being tagged in this comment it is due to an entry in the related Maestro Subscription of the Build Asset Registry. If you feel this entry has added your GitHub login or your GitHub team in error, please update the subscription to reflect this.
• For more details, please read the Arcade Darc documentation

[jeffschwMSFT]

rerunning due to ephemeral download issue

Failed to download package 'System.Composition.Runtime.9.0.0-preview.5.24272.3' from 'https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/a54510f9-4b2c-4e69-b96a-6096683aaa1f/nuget/v3/flat2/system.composition.runtime/9.0.0-preview.5.24272.3/system.composition.runtime.9.0.0-preview.5.24272.3.nupkg'.
Response status code does not indicate success: 503 (Service Unavailable).

[v-wuzhai]

@dotnet/illink Could you take a look at the failures here?

[vitek-karas]

This is very likely due to dotnet/runtime#102528. @jtschuster could you please take a look?
I vaguely remember that there are cases where the source is an assembly (assembly level attributes I think) - which is not a "member".

https://github.com/dotnet/runtime/blob/4c8a235abd8b510a3f8a5161bea03abd5b69896c/src/tools/illink/src/linker/Linker.Steps/MarkStep.cs#L3513

Should probably look like:

origin = resource.Source is IMemberDefinition ? new MessageOrigin((IMemberDefinition)resource.Source) : origin;

[jeffschwMSFT]

@jtschuster can you take a look at the failures?

�[m�[37m        Fatal error in IL Linker
�[m�[37m        Unhandled exception. System.InvalidCastException: Unable to cast object of type 'Mono.Cecil.AssemblyDefinition' to type 'Mono.Cecil.IMemberDefinition'.

[sbomer]

I think we just need dotnet/runtime#102613 to flow and are waiting for an official build to succeed.

[jeffschwMSFT]

right, the official build is struggling. I saw that it was merged, but did not put it together that it was waiting for an updated build

[jeffschwMSFT]

rerunning in the hope that the docker failures are ephemeral

[kasperk81]

�[31;1m    Microsoft.NET.Build.Containers.IntegrationTests.DockerRegistryTests.GetFromRegistry [FAIL]
�[m�[37m      System.InvalidOperationException : The registry was not loaded after 5 retries. Spawn registry attempt #1 failed, System.ApplicationException: CONTAINER1001: Failed to upload blob using PUT http://localhost:5010/v2/dotnet/runtime/blobs/uploads/b9ecd41a-4a7a-4902-96d3-98f94a2c52d5?_state=ywtSR-HjrC26pbATF-YJHI3nkv0wXS6C-hjFjg0w34J7Ik5hbWUiOiJkb3RuZXQvcnVudGltZSIsIlVVSUQiOiJiOWVjZDQxYS00YTdhLTQ5MDItOTZkMy05OGY5NGEyYzUyZDUiLCJPZmZzZXQiOjE0OTY3MzEzLCJTdGFydGVkQXQiOiIyMDI0LTA1LTI4VDA1OjIyOjU2WiJ9&digest=sha256%3Aaff7a9c037c8fa6f1c4f3fbbf33d19a638633b2d47eaece0411fed15cb3e10c6; received status code 'BadRequest'.
�[m�[37m         at Microsoft.NET.Build.Containers.DefaultBlobUploadOperations.CompleteAsync(Uri uploadUri, String digest, CancellationToken cancellationToken) in /_/src/Containers/Microsoft.NET.Build.Containers/Registry/DefaultBlobUploadOperations.cs:line 40
�[m�[37m         at Microsoft.NET.Build.Containers.Registry.UploadBlobAsync(String repository, String digest, Stream contents, CancellationToken cancellationToken) in /_/src/Containers/Microsoft.NET.Build.Containers/Registry/Registry.cs:line 418
�[m�[37m         at Microsoft.NET.Build.Containers.Registry.PushLayerAsync(Layer layer, String repository, CancellationToken cancellationToken) in /_/src/Containers/Microsoft.NET.Build.Containers/Registry/Registry.cs:line 329

[jeffschwMSFT]

@MichaelSimons can your team take a look? looks like a docker container connection/restore issue

[MichaelSimons]

@MichaelSimons can your team take a look? looks like a docker container connection/restore issue

It is not obvious how this is A&D team related. Respectfully just because it is a container issue, doesn't mean the A&D team should investigate. This looks related to "Microsoft.NET.Build.Containers". @joperezr are these tests you/your team owns? Any suggestions?

[baronfel]

Those tests are around the .NET SDK container publishing feature - we spawn a container using registry:2 and push/pull images from it to verify registry access. We haven't had a lot of failure recently there - @marcpopMSFT I'd treat this as a test-infra failure, retry, and if it pops up again get one of the @dotnet/sdk-container-builds-maintainers to dig in.

[kasperk81]

if it is consistently failing only in this pr for several commits, it has to be something which changed in runtime?

[jeffschwMSFT]

@dotnet/sdk-container-builds-maintainers please take a look this is now a durable failure.

[nagilson]

@MichalPavlik Do you have bandwidth to look at this containers registry issue that has popped up following this runtime change?

[marcpopMSFT]

Per Chet above, filed a tracking issue: #41272 Might be worth disabling the test to get runtime unblocked though there's a chance that runtime is causing the issue since so far it only repros in this PR.

[kasperk81]

ONTAINER1001: Failed to upload blob using PUT http://localhost:5010/v2/dotnet/runtime/blobs/uploads/[id]

if this test running on other prs that means it is passing and the [id] part is being updated by this pr which is causing the failure

[MichalPavlik]

Hey, it's already night here, so I have capacity to diagnose the test tomorrow, my time zone. I tried to take a brief look, but I'm not sure right now what's wrong.
@baronfel, you have your own set of functional tests. Are you able to confirm that it's working with updated dependencies? If so, I'm for disabling the test (until we find the failure reason) to unblock the update.
Sorry folks, I would continue but my brain is giving me signals that it's time to wrap it up today.

[nagilson]

No worries, I wouldn't expect anyone to be checking their GH pings around midnight. Thank you for following up with us.

[MichalPavlik]

My suspicion was incorrect state of Docker engine on the CI machine, but I wanted to run/debug the test locally on the Ubuntu WSL instance. I wasn't successful so far and now I see all checks are green :|
Still, I would like to be able to debug tests in SDK repo using Ubuntu with VS. In the past, I was able to do it with VS Remote Testing (different repo), but it didn't work this time with SDK repo. VS stuck on installing .NET runtime on the target OS. Maybe it's an issue with current VS main version but even if VS installs the runtime, it would be a current stable version. So, sorry for the off-topic question, but it's there any guidance how to debug SDK test running in Ubuntu using VS?

[baronfel]

@MichalPavlik for what it's worth you don't need to debug the tests on Ubuntu - they only run on the Ubuntu leg in CI because we do not have Docker licenses on the CI runners. As long as you have Docker running locally they are debuggable on Windows. I'm not sure why the tests are green but I'll take it!

[MichalPavlik]

@baronfel checking tests on Windows was too easy :D All was green on my machine, but I wanted to be thorough. At the end, I was able to run all tests in the project on Ubuntu, and except one skipped test, all was green as well. I'm not sure why these tests failed in CI, but I'm also glad it's resolved.