Browser WASM collectible ALC test has no loadable assembly path

[lewing]

Description

Async2CollectibleAlc.TestEntryPoint fails on browser-Wasm CoreCLR because the host does not expose a usable assembly path for loading a second copy into a collectible AssemblyLoadContext.

Reproduction Steps

Build browser-Wasm CoreCLR and run:

src/tests/async/collectible-alc/collectible-alc.cs
Async2CollectibleAlc.TestEntryPoint

The failure reproduces in both interpreter and ReadyToRun execution.

Expected behavior

The test should locate a loadable copy of collectible-alc.dll, load it into a collectible AssemblyLoadContext, execute the runtime-async method, unload the context, and pass.

Actual behavior

Assembly.GetExecutingAssembly().Location is empty in the browser host, and AssemblyLoadContext.LoadFromAssemblyPath fails before the runtime-async assertions execute:

System.ArgumentException: Path "" is not an absolute path. (Parameter 'assemblyPath')
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at Async2CollectibleAlc.CallFooAsyncInCollectibleALC(Task task)

Regression?

Unknown. This was exposed while enabling the full src/tests/async runner for browser CoreCLR.

Known Workarounds

Skip only Async2CollectibleAlc.TestEntryPoint when PlatformDetection.IsWasm is true. Preserve native-platform coverage.

Configuration

• Browser CoreCLR
• WebAssembly
• Checked runtime, Release libraries
• Interpreter and ReadyToRun execution under Node

Other information

A complete fix needs a browser-host-supported mechanism for supplying the test assembly bytes or a loadable path to the collectible ALC.

Note

This issue was generated with GitHub Copilot assistance.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @elinor-fung
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

Related
#132308
#122972