Description

LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists and dlopen succeeds. This scenario requires Emscripten dynamic linking (-s MAIN_MODULE=1 / -s SIDE_MODULE=1), which the .NET SDK does not enable by default, but the runtime should still resolve symbols correctly when it is used. Today the runtime only checks the generated pinvoke table and does not honor a dynamic module map for dlopen/dlsym resolution.

Reproduction Steps

1. Build a browser-wasm app with Emscripten main module support:
   • Link flags: -s MAIN_MODULE=1
2. Build a side module with one exported function:
   • emcc -O0 -s SIDE_MODULE=1 -s EXPORT_ALL=1 -o libmylib.wasm side-module.c
   • side-module.c:

     int side_add(int a, int b) { return a + b; }
     

3. Add dynamic module mapping to runtimeconfig.template.json:

   {
     "runtimeOptions": {
       "configProperties": {
         "extensions.System.Runtime.InteropServices.JavaScript.DylinkModules": "mylib=libmylib.wasm"
       }
     }
   }
   

4. Use LibraryImport in managed code:

   [LibraryImport("mylib", EntryPoint = "side_add")]
   internal static partial int SideAdd(int a, int b);
   

5. Run the app.

Expected behavior

LibraryImport resolves side_add from libmylib.wasm and returns correct results.

Actual behavior

LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen succeeding.

Regression?

Unknown (not tested against previous releases).

Known Workarounds

Link native code into the main module (no side module) so the symbol is present in the generated pinvoke table.

Configuration

• .NET version: main (net11.0).
• Runtime: Mono browser-wasm.
• Build flags: WasmBuildNative=true, -s MAIN_MODULE=1 (main module), -s SIDE_MODULE=1 -s EXPORT_ALL=1 (side module).
• Toolchain: Emscripten from the wasm workload or EMSDK_PATH.
• OS/distro: Expected independent of OS; CI usually Linux x64.
• Architecture: Expected independent of arch (x64 in CI).
• Browser/host: Expected independent; wasm test infra typically uses Chromium.

Other information

Runtime currently prioritizes pinvoke table lookups; a dynamic module map should be consulted after that for dlopen-based resolution.