Skip to content

Improve C# WASM runtime binding loading and logging#147

Open
Arnold-Seb wants to merge 3 commits into
thoth-tech:mainfrom
Arnold-Seb:fix/csharp-binding-rewire
Open

Improve C# WASM runtime binding loading and logging#147
Arnold-Seb wants to merge 3 commits into
thoth-tech:mainfrom
Arnold-Seb:fix/csharp-binding-rewire

Conversation

@Arnold-Seb
Copy link
Copy Markdown

@Arnold-Seb Arnold-Seb commented Apr 11, 2026

Description

This change improves the stability of the C# WebAssembly runtime in SplashKit Online by addressing issues in the JavaScript binding layer.

During testing, the runtime failed to initialise reliably due to the binding loader attempting to resolve all generated SplashKit functions using eval(). Since many of these functions are not available in the browser runtime, this resulted in runtime crashes and prevented C# programs from executing correctly.

The binding logic in CSharpWasmExpo/main.js has been updated to safely check for function availability before assignment. Missing functions are now skipped, and warnings are logged instead of causing failures. This allows the runtime to initialise successfully even when bindings are incomplete.

Additionally, basic handling for process_events has been introduced to improve debugging visibility when the function is not properly wired.

This change resolves the runtime initialisation crash and provides clearer insight into missing bindings, supporting further investigation of incomplete API coverage in the C# runtime.

Fixes # (runtime initialisation crash caused by missing JS bindings)


Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Documentation (update or new)

How Has This Been Tested?

The changes were tested locally using the SplashKit Online development environment.

Steps:

  1. Clone the repository
  2. Start the server using npm start
  3. Open the application in the browser (localhost:8000)
  4. Select C# and run a sample program

Expected / Observed Results:

  • Runtime initialises without crashing
  • Previously failing executions now proceed without fatal errors
  • Missing functions are logged clearly in the browser console
  • Identified that process_events is still not fully wired, confirming improved debugging visibility

Testing Checklist

  • Tested in latest Chrome

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings

Copy link
Copy Markdown

@kottochii kottochii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes are legitimate and solve the problem of quiet failures, exposing the root problems with method referencing.

I, however, would like to keep an issue in the backlog to resolve the missing bindings.

Copy link
Copy Markdown
Contributor

@cameronhum cameronhum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code works and does what it aims where it fixes JS binding for the C# wasm setup and adds a fallback for process events. I have checked it and as seen in the below image it works.

before I approve I want to check the reasoning for the implementation straight into a generative file (as a temporary fix is fine but this will be overwritten eventually due to the files nature) and if we are able to simplify the logs so it causes less console spam.

if you can fix/justify these I am happy to push to next review

Image


[JSImport("SplashKitBackendWASM.draw_circle", "main.js")]
public static partial void DrawCircle(int color, double x, double y, double radius);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary to add? Since this is a generated file should this be excluded from this pr? i saw you said you implemented missing bindings is that related to "Compare SplashKit.cs with generated bindings" if so this is reasonable as a quick fix although should be fixed at the core (generation, potentially a new task)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You’re right — I’ve removed the manual change from SplashKitBindings.Generated.cs since it is a generated file and would likely be overwritten later.

The original intent was to quickly validate whether the missing binding was related to generated bindings versus the runtime wiring itself. I’ve now kept the fix focused on the JS binding/runtime side only, and the missing bindings should instead be addressed properly through the generation process in a separate task.

Comment thread CSharpWasmExpo/main.js Outdated
if (typeof window[name] === "function") {
bindingsFunctions[name] = window[name];
} else {
console.warn(`[SplashKit WASM] Missing function: ${name}`);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

much more intentional and doesn't rely on crashes to occur. good job. however this can be quite 'spammy' since it runs every single time a build occurs. can we put this into a single warning instead?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated this so the missing bindings are now reported through a single warning instead of logging one warning per function.

I also moved the detailed list into a collapsed console group so the console stays cleaner during builds while still keeping the missing bindings easy to inspect for debugging.

Screenshot 2026-05-08 212452 image

Copy link
Copy Markdown
Contributor

@cameronhum cameronhum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked after the changes and it addresses everything i mentioned. I approve it now to go onto the next review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants