Repository navigation
[wasm][coreclr] Call-helper generation fails when the bundle contains an assembly deployed under a different file name #134915
Description
Description
CoreCLR WebAssembly app builds generate per-app call helpers by running crossgen2 with
--generate-portable-callhelpers over every managed assembly in the bundle
(WasiApp.CoreCLR.targets _WasiCoreCLRRelinkCoreRun; BrowserWasmApp.CoreCLR.targets uses the
same FilterManagedAssemblies step). crossgen2 requires each input's assembly name to match its file
name (CompilerTypeSystemContext), so the build fails when an app deploys an assembly under another
file name and loads it by path.
System.Runtime.Loader.DefaultContext.Tests does exactly this: it deploys
System.Runtime.Loader.Noop.Assembly as System.Runtime.Loader.Noop.Assembly_test.dll. WASI CoreCLR
relinks the host for every app, so it always runs the generator and fails. Browser CoreCLR runs the
generator only when the app is relinked (WasmBuildNative), so the browser library lanes, which use the
prebuilt runtime for this suite, don't hit it. A relinked browser app that deploys such an assembly
would fail the same way: both platforms pass every published .dll to the generator.
EXEC : error : Assembly name does not match filename .../System.Runtime.Loader.DefaultContext.Tests/Release/net11.0/wasi-wasm/AppBundle/managed/System.Runtime.Loader.Noop.Assembly_test.dll
src/mono/wasi/build/WasiApp.CoreCLR.targets(283,5): error MSB3073: The command ".../crossgen2" "@.../callhelpers-generator.rsp" exited with code 1.
Seen in the wasi-wasm linux Release LibraryTestsCoreCLR_WASI lane of
#134813
(build 1617382).
Expected
Assemblies deployed under another file name are still loaded at runtime, so their P/Invoke and
reverse P/Invoke signatures need call helpers. Skipping them would avoid the build error but can
leave missing helpers that only fail at runtime. A possible fix is to stage a copy named after the
assembly's metadata name for the generator, leaving the bundle layout unchanged.
Re-enable
Remove the WASI CoreCLR ProjectExclusions entry for
System.Runtime.Loader.DefaultContext.Tests in src/libraries/tests.proj once call-helper
generation accepts such assemblies.
Note
This issue was drafted with the help of GitHub Copilot.
Activity
dotnet-policy-service commentedon Sep 30, 2026
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
[wasi] Exclude System.Runtime.Loader.DefaultContext.Tests on CoreCLR …
[wasi] Exclude System.Runtime.Loader.DefaultContext.Tests on CoreCLR …
[wasi] Exclude System.Runtime.Loader.DefaultContext.Tests on CoreCLR …
[wasi] Exclude System.Runtime.Loader.DefaultContext.Tests on CoreCLR …
[wasi] Exclude System.Runtime.Loader.DefaultContext.Tests on CoreCLR …
[wasi] Exclude System.Runtime.Loader.DefaultContext.Tests on CoreCLR …
lewing commentedon Oct 26, 2026
Additional analysis on the fix direction:
The "Assembly name does not match filename" check is not specific to crossgen2's WASM mode. It lives in the shared
CompilerTypeSystemContext.AddModule(src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.cs, ~L234) and only fires when a module is resolved by simple name through the file-name-keyedInputFilePaths/ReferenceFilePaths(GetModuleForSimpleName). Loading by explicit path (GetModuleFromPath) passesexpectedSimpleName = nulland skips it. The runtime itself never checks the file name, which is why regular builds and runs pass: nothing else compiles the renamed assembly.Staging a correctly named copy would unblock the generator, but it's a workaround. Call-helper generation only needs P/Invoke and reverse P/Invoke signatures, not the file-name-to-identity binding. A more targeted fix would be for
--generate-portable-callhelpersto load its inputs by path (or relax the check in that mode), which removes the copy step and also covers the browser relink case. I haven't verified which input path the callhelpers mode takes today.Note
This comment was drafted with the help of GitHub Copilot.
jkotas commentedon Oct 27, 2026
I am not sure there is anything to fix. Many places in .NET SDK and other tooling assume that assembly name and file name match. If they do not match, you are on your own and cannot expect that the tooling is going to work well.
lewing commentedon Oct 27, 2026
Should we fix the tests then? System.Runtime.Loader.DefaultContext.Tests.csproj has this problem.
jkotas commentedon Oct 27, 2026
Can we disable the test for the test modes where it is causing problems?
The test is intentionally testing the behavior when AssemblyLoadContext.LoadFromAssemblyPath API is passed a filename that does not match the assembly name.