Repository navigation
[ci-scan] Test failure: AssemblyTests.AssemblyLoadWithPublicKey (iossimulator-arm64) #129149
Description
Activity
Workflow artifact: ci-fix
Artifact kind: handoff
Linked KBE: #129149Note
AI/Copilot-generated triage note.
This Known Build Error has no producible automated code change (reason: product bug in the assembly loader on iossimulator-arm64 CoreCLR — the fix requires changes to assembly resolution internals that exceed automated small-fix bounds), so I could not open even a best-effort PR. Looping in owners so it can be fixed forward rather than muted.
Root cause (best analysis)
AssemblyTests.AssemblyLoadWithPublicKeyfails on iossimulator-arm64 (AllSubsets_CoreCLR) becauseAssembly.Load(new AssemblyName("System.Runtime"))throwsFileNotFoundException:System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.The test creates an
AssemblyNamewith just the simple name "System.Runtime" (no version, no public key token, no culture), then callsAssembly.Load(). On most platforms, the assembly resolver successfully locatesSystem.Runtimeby simple name alone. On iossimulator-arm64 CoreCLR, the resolution fails — likely due to a difference in how the iOS app bundle layout or trimming affects assembly probing when thePublicKeyTokenis null.The second failing test (
AssemblyGetForwardedTypesLoadFailure) likely depends on the same resolution path.Evidence
- Failing build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1452872
- First build it occurred: build 1449088, 2026-06-04T09:47:08Z (computed within the scanned window; may not be the true origin)
- Not present in build 1442382 (2026-05-31); regression likely introduced between May 31 and June 4
- Possible related PR: none identified with sufficient confidence — no assembly loader commits found in the window
Suggested reviewers / area contacts
- Area owners (
area-AssemblyLoader):@elinor-fung,@dotnet/runtime-infrastructure
A fix would likely involve adjusting the assembly probing logic on iOS to correctly resolve assemblies by simple name when no public key token is specified, similar to how other platforms handle this case.
Note
🔒 Integrity filter blocked 2 items
The following items were blocked because they don't meet the GitHub integrity level.
- #128501
search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - [ci-scan] Test failure: CryptoStreamTests.ReadWrite_Success MemberData not found on maccatalyst #128451
issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
To allow these resources, lower
min-integrityin your GitHub frontmatter:tools: github: min-integrity: approved # merged | approved | unapproved | none
Generated by CI Outer-Loop Failure Fixer · ● 20.1M · ◷
removing blocking-clean-ci as it has not failed in 30 days
24-Hour Hit Count 7-Day Hit Count 1-Month Count 0 0 0 - locked and limited conversation to collaborators
on Aug 24, 2026
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1452872
Build error leg or test failing: iossimulator-arm64 Release AllSubsets_CoreCLR - System.Reflection.Tests
Error Details
Two tests in
System.Reflection.Tests.AssemblyTestsconsistently fail on iossimulator-arm64 CoreCLR:Affected legs:
First build it occurred:
Error Message
{ "ErrorMessage": ["System.Reflection.Tests.AssemblyTests.AssemblyLoadWithPublicKey", "Could not load file or assembly 'System.Runtime, Culture=neutral, PublicKeyToken=null'"], "ErrorPattern": "", "BuildRetry": false, "ExcludeConsoleLog": false }Filed by
ci-failure-scan, which scans dnceng-public outer-loop pipelines onmainand converts stable failures into KBEs and test-disable PRs. Comment here or on the workflow file to suggest changes;ci-failure-scan-feedbackreads in-scope feedback daily and opens (or updates) a PR with prompt edits.Note
🔒 Integrity filter blocked 5 items
The following items were blocked because they don't meet the GitHub integrity level.
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".To allow these resources, lower
min-integrityin your GitHub frontmatter:Report
Summary