.NET NativeAOT WASM output fails with "null function or function signature mismatch" when transpiled for Node.js

[dirkwa]

Summary

WASM components produced by componentize-dotnet (.NET NativeAOT) fail at runtime when transpiled with jco for use in Node.js/V8.

Environment

• jco version: latest (Dec 2024)
• .NET versions tested: 8, 9, 10
• componentize-dotnet: latest
• Node.js: 20.x
• Platform: Linux

Error

When running the transpiled component in Node.js:

RuntimeError: null function or function signature mismatch

The .NET NativeAOT function tables fail to initialize properly in V8.

Steps to Reproduce

1. Create a minimal .NET WASM component using componentize-dotnet
2. Transpile with jco for Node.js
3. Import and instantiate in Node.js
4. Runtime crash occurs

What Was Tried

• jco transpilation with various flags
• Manual _initialize() calls
• Removing [ThreadStatic] attribute from .NET code
• Different .NET versions (8, 9, 10)

None resolved the issue.

Context

We're trying to support C#/.NET as a language option for WASM plugins in Signal K Server. Rust, AssemblyScript, and Go/TinyGo all work correctly with jco transpilation, but .NET does not.

The componentize-dotnet README states support for Wasmtime and WAMR runtimes, but doesn't mention jco/V8/Node.js compatibility.

Question

Is jco expected to work with .NET NativeAOT output from componentize-dotnet? If not, are there plans to support it, or is there a recommended workaround?

References

• componentize-dotnet

[vados-cosmonic]

hey @dirkwa thanks for pointing this out -- would love to get some more test cases of C# in the codebase -- not sure what could have gone wrong here.

Would you mind contributing a small test case that shows the interface you were trying (interested to see how complex it is, etc)?

[dirkwa]

@vados-cosmonic
A nice BULA (good morning) from Fiji.
Thanks for looking into this! I've put together a minimal reproduction repo:

Repo: https://github.com/dirkwa/jco-issue-1173

The WIT interface (as simple as it gets)

package test:minimal@1.0.0;

interface plugin {
    get-id: func() -> string;
}

world minimal {
    export plugin;
}

C# implementation

namespace MinimalWorld.wit.exports.test.minimal.v1_0_0;

public class PluginImpl : IPlugin
{
    public static string GetId() => "hello from dotnet";
}

Reproduction steps

git clone https://github.com/dirkwa/jco-issue-1173
cd jco-issue-1173
npm install

# Build (needs .NET 10 SDK and WASI_SDK_PATH set)
dotnet build -c Release

# Transpile
npx @bytecodealliance/jco transpile \
  bin/Release/net10.0/wasi-wasm/publish/Minimal.wasm \
  -o jco-output --name minimal --tla-compat

# Run - this crashes
node test.mjs

What happens

Loading .NET WASM component via jco...
$init completed
Calling plugin.getId()...
Error: null function or function signature mismatch
RuntimeError: null function or function signature mismatch
    at S_P_CoreLib_Internal_Runtime_CompilerHelpers_StartupCodeHelpers__InitializeGlobalTablesForModule
    at S_P_CoreLib_Internal_Runtime_CompilerHelpers_StartupCodeHelpers__InitializeModules
    at InitializeRuntime()
    ...

The crash happens during .NET runtime initialization when the first exported function is called. Looks like the indirect call tables aren't getting set up properly in V8.

A note about the patches in the repo

You'll notice I have a patch-threadstatic.sh script that runs during build. The wit-bindgen output from componentize-dotnet uses [ThreadStatic] attributes which aren't available in single-threaded WASI, so I strip those out. Also had to add using System; to some generated files. These are just workarounds to get it to compile - the actual runtime crash is a separate issue.

Environment tested

• .NET SDK: 10.0.101
• componentize-dotnet: 0.7.0-preview00010
• jco: 1.15.4
• Node.js: 22.21.0
• Debian 13 (x86_64)

Happy to provide the compiled .wasm file directly if that helps, or run any additional diagnostics you need!

[dirkwa]

@vados-cosmonic

Happy new year!
Could you reproduce the issue with the test repo I shared with you?

Thanks and all the best!

[dirkwa]

Hi, any news?

[vados-cosmonic]

Hey @dirkwa right now, my main focus is getting preview 3 (async) of the component model completed -- I don't think I'll be able to get to debugging this anytime soon. I am happy to take any pull requests if you find something that's Jco relevant though.

One path that might be worth going down is making sure that your component works with wasm-tools component unbundle and can be loaded by V8, since this is one step of what Jco does with your component (i.e. a transpiled component is an "unbundled" component with JS glue -- it sounds like this problem might be at the unbundling level).

[dirkwa]

@vados-cosmonic

After some deeper analysis the root seems to be in wit-bindgen.
I will track it further down and hopefully come up with a PR.

[dirkwa]

Summary: .NET WASM Library Component Initialization Bug

Problem

.NET NativeAOT WASM library components (reactors) crash with "uninitialized element" trap (IndirectCallToNull) when exported functions are called directly via wasmtime or jco. The error occurs because the .NET runtime's RhpReversePInvoke function uses call_indirect which requires the function table to be initialized first.

 

GitHub Issue: #1173

Root Cause

The issue is in WASI SDK 24.0 which ships with an older version of wasm-component-ld:

Component | WASI SDK 24.0 | Fixed Version
-- | -- | --
wasm-component-ld | 0.5.6 (July 2024) | 0.5.7+
wit-component | 0.215.0 | 0.216.0+

The fix (commit 108c37d9 in wasm-tools, August 29, 2024) adds a start-shim module that calls _initialize at component instantiation time, before any exports can be accessed. This ensures the .NET runtime is fully initialized (including function tables) before any export is called.

wit-bindgen PR #1489

Keep it open - The EnsureInitialized() call added in PR #1489 is still valuable as a defense-in-depth measure. Once _initialize runs via the start-shim, the check becomes a fast no-op. It provides safety in case the component is used in an environment that doesn't honor the component model's initialization semantics.

Workaround

Replace wasm-component-ld in your WASI SDK installation with a newer version:

# Clone and build the latest wasm-component-ld
git clone https://github.com/AzureGreen/wasm-component-ld
cd wasm-component-ld
cargo build --release

# Replace the binary in WASI SDK (adjust path as needed)
cp target/release/wasm-component-ld ~/.wasi-sdk/wasi-sdk-24.0/bin/wasm-component-ld

# Verify the version (should be 0.5.7 or higher)
~/.wasi-sdk/wasi-sdk-24.0/bin/wasm-component-ld --version

Then rebuild your .NET project:

rm -rf bin obj

dotnet build

Permanent Fix

Wait for WASI SDK 25+ which should include the updated wasm-component-ld with the start-shim fix.

Technical Details

The start-shim module generated by the fixed wasm-component-ld looks like:

(core module $start-shim-module

(type (func))

(import "" "" (func (type 0)))

(start 0)  ;; Calls _initialize at instantiation

)

This module is instantiated with the main module's _initialize export, ensuring the .NET runtime is fully initialized before any component exports become accessible.

[vados-cosmonic]

Thanks for chasing this down @dirkwa -- this should serve as a useful resource for anyone who runs into it until the newer version of wasi-sdk is out.