Skip to content

WebAssembly/NodeJS Demo - SSE HTTP server with ASP.NET core pipelines #383

@pavelsavara

Description

@pavelsavara

Make it easier to run C# MCP server via nxp only

(without dotnet native installation on the target machine)

https://github.com/pavelsavara/node-mono-server

You can also try this on machine which doesn't have dotnet installed but is has nodejs/npx.

npx @pavelsavara/express-csharp-mcp-echo

Implementation details and underlying support

This is demonstrating how to run ASP.NET Core middleware pipeline on top of NodeJS/Express HTTP server with zero native files.

The dotnet VM is Mono interpreter compiled into WASM in for the Browser target.
The integration with Express HTTP server is done via [JSImport]/[JSExport] interop.
At the moment the implementation is naive HTTP/1.1 only with response streaming, no WS, no HTTP/2.
The other MCP transport types are not implemented yet.

The dotnet runtime supports Browser "operating system" and it also works on NodeJS.
But NodeJS it's not supported target in Net10 or older.
The aspnetcore server side doesn't support browser RID.
This demo is hacking it's MSBuild scripts in unsupported and undocumented way in order to fabricate Microsoft.NET.Sdk.Web for browser-wasm RID.
Both limitations could be fixed.

Other limitations

The RID is single-threaded environment. You can't use C# threads and locks. You can't use C# sockets.

WASI alternative

The same demo could be implemented on top of WASI target of dotnet runtime and wrapped by JCO.
The wasi:http preview 2 handler also works in similar way. I have some draft too.

Downsides compared to Browser target are

  • WASI is less mature
  • WASI is not yet a supported product/target of dotnet
  • WASI HTTP server host is creating new component instance (memory) for each request.
    That's not compatible with running long lived MCP session in-process.
    This could be fixed by implementing session persistence via another WASI component, such as wasi:keyvalue

Benefits

  • WASI granular security model could isolate the component from touching unexpected resources on the local machine. Such as local disk, environment variables, network, HTTP endpoints etc. Making it easier to trust 3rd party MCP server implemented in WASI than to trust running NPM module on your machine.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions