Move WASM to CoreCLR to unlock more platfroms?

[universorum]

Cloudflare Workers is a hugely popular serverless platform that supports WebAssembly. Today, you can use it to run Hono for path-based request routing, and even execute Rust code compiled to Wasm via the wasm32-unknown-unknown toolchain.

Currently, the only way to run a .NET application on Cloudflare is through containers, which are expensive. If ASP.NET Core could run in Wasm, we could deploy it to Cloudflare Workers without needing a container at all.

However, in .NET 11 Preview 7, attempting to compile an ASP.NET Core Minimal API project for WASM produces the following error: NETSDK1082: There was no runtime pack for Microsoft.AspNetCore.App available for the specified RuntimeIdentifier 'browser-wasm'.

I guess thet is because WASM is using mono, not CoreCLR. Starting .NET 11, WASM is only Microsft supported platform using mono (Unity is not supported by Microsoft and is will be supported s∞n in Unity 6.6(preview)/6.7).

I guess this is because the Wasm runtime uses Mono, not CoreCLR. Starting with .NET 11, Wasm is the only Microsoft-supported platform still running on Mono. (Unity is not supported by Microsoft directly, and it will add .NET support s∞n in Unity 6.6 (preview) or 6.7).

var builder = WebApplication.CreateSlimBuilder(args);
// AOT builder setup

var app = builder.Build();
// Mapping minimal API

var handler = ((IApplicationBuilder)_webApplication).Build();

[JSExport]
static async Task<HttpResponse> HandleAsync(HttpRequest request)
{
  await using var scope = app.Services.CreateAsyncScope();
  var context = new DefaultHttpContext
  {
      RequestServices = scope.ServiceProvider,
      Request = request,
      // {
      //     Method        = HttpMethods.Phst,
      //     Path          = "/echo",
      //     ContentType   = "application/json",
      //     ContentLength = requestStream.Length,
      //     Body          = requestStream
      // },
      Response = { Body = new MemoryStream() }
  };
  
  await pipeline(context);
  
  return context.Response;
}

import { dotnet } from './_framework/dotnet.js'

const { getAssemblyExports, getConfig, runMain } = await dotnet
    .withApplicationArguments("start") // these are the args passed to the program
    .create();

const config = getConfig();

const exports = await getAssemblyExports(config.mainAssemblyName);

export default {
	async fetch(request, env, ctx) {
		return await exports.AspNetCore.handleAsync(request);
	},
};

[Suchiman]

In .NET 11, you can use <UseMonoRuntime>false</UseMonoRuntime> to use CoreCLR with WASM.
The real issue here is that WASM is a sandboxed environment without access to the outer world by default.
In order to receive web requests you need a custom server that receives requests through the cloudflare worker APIs and then channels it through the ASP.NET Core pipeline.

[huoyaoyuan]

wasm on coreclr is still WIP. As announced before it won't come together with mobile platforms in .NET 11. The current ETA is .NET 12.

[lewing]

There are two separate things being conflated here, and untangling them explains both the error and why the suggested fix won't help.

Runtime flavor and runtime pack are different things. <UseMonoRuntime>false</UseMonoRuntime> selects CoreCLR instead of Mono. NETSDK1082 is complaining about a runtime pack for Microsoft.AspNetCore.App, which doesn't exist for browser-wasm under either flavor — the ASP.NET Core shared framework simply isn't built for a wasm RID. Changing the runtime flavor doesn't produce that pack, so you'd hit the same error either way.

(For what it's worth, @huoyaoyuan is right on the status: CoreCLR-on-wasm is in progress in-tree but is not a .NET 11 deliverable.)

browser-wasm is the wrong target regardless. It's a browser RID. There are no sockets, so there's no Kestrel, and more fundamentally its bootstrap (dotnet.js) fetches and instantiates dotnet.native.wasm at runtime. Cloudflare Workers forbids exactly that — WebAssembly.compile, compileStreaming, instantiateStreaming, and WebAssembly.instantiate with a buffer are all blocked for security reasons, as are eval and new Function (docs). Wasm modules have to be bound at deploy time. So the JS snippet in the original post can't boot on Workers even setting ASP.NET Core aside.

The plumbing you'd actually want is wasi-wasm, plus a custom server that feeds the Worker's fetch event into the ASP.NET Core pipeline — which is what @Suchiman said in his second paragraph, and it's the real answer. Note that WASI on Workers is explicitly experimental with only some syscalls implemented, and there's no component-model/WASI 0.2 support.

The constraints on Workers are the harder part. Even with a working WASI host: no threads, 128 MB memory, 64 MiB worker size, and a 1 second startup-time budget. Those are real obstacles for a full framework, not paperwork.

The useful precedent is Python Workers, which runs FastAPI today. That didn't happen by fixing a runtime pack — Cloudflare embedded Pyodide into workerd itself and wrote an ASGI-style request shim. .NET on Workers would need the equivalent on both sides: a WASI-hosted runtime here, and a Cloudflare-side hosting model there. Neither exists yet, and the second one isn't something this repo can deliver.

So: this isn't blocked on Mono vs. CoreCLR. It's blocked on a WASI hosting story plus a Cloudflare-side integration.

Note

This reply was drafted with the assistance of GitHub Copilot.