LibraryImport fails to resolve side modules on browser-wasm #123570

Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future

Description

@denis-kudelin
denis-kudelin
opened on Jan 24, 2026

Description

LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.

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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing): 
    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.

Actual behavior

LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.

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).

Other information

Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).

Metadata

Metadata

Assignees

Labels

arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm

Type

No type

Projects

  • AppModel
    Status
    No status

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
LibraryImport fails to resolve side modules on browser-wasm #123570
Open
#131533
Open
LibraryImport fails to resolve side modules on browser-wasm#123570
#131533
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Milestone
Future
Description
@denis-kudelin
denis-kudelin
opened on Jan 24, 2026
Description
LibraryImport on browser-wasm fails to resolve symbols from Emscripten side modules even when the module exists in the app bundle and dlopen would succeed. 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 attempt dlopen for non-table names, so side modules cannot be resolved.
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. Ensure the side module is included in the app bundle (e.g., WasmNativeAsset with TargetPath = libmylib.wasm so it exists in the virtual FS).
  4. Use LibraryImport in managed code (note: no extension in the name to exercise suffix probing):

    [LibraryImport("libmylib", 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. Names without an explicit extension should be probed with the platform suffix (WASM: .wasm), so libmylib and libmylib.wasm are equivalent.
Actual behavior
LibraryImport fails with DllNotFoundException or EntryPointNotFoundException, despite the side module being present and dlopen being able to load it. The runtime never attempts dlopen for non-table names.
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).
Other information
Runtime currently prioritizes pinvoke table lookups and does not fall back to dlopen for non-table names. For dynamic linking, it should attempt dlopen(name) after the pinvoke table check and rely on the platform suffix probing (WASM: .wasm).
Metadata
Metadata
Assignees
Labels
arch-wasmWebAssembly architecturearea-Interop-monoos-browserBrowser variant of arch-wasm
Type
No type
Projects
  • AppModel
    Status
    No status
Milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions