31

I want to be able to call C# code from JavaScript. The mono project used to have a WASM SDK that you could download from their old Jenkins server, but that is no longer public. Existing docs tend to point toward those builds. The Azure Devops builds do not include this SDK. A few messages I've seen on their Github account indicate that they are now focusing on the .NET 6 for WASM. I do not wish to use the Blazor components. Is there a way in .NET 6 to build a minimally sized WASM binary without the Blazor UI?

eltiare
  • 1,817
  • 1
  • 20
  • 28
  • The Mono WASM SDK became Blazor. `I do not wish to use the Blazor components.` why? – Panagiotis Kanavos Aug 25 '21 at 17:41
  • 2
    The UI components. I just want to compile C# and call it from JavaScript and vice versa. – eltiare Aug 25 '21 at 22:08
  • 3
    "why?" Is that a serious question? – Emperor Eto Aug 26 '21 at 01:21
  • 2
    Unfortunately, probably is. A lot of people don't believe in framework diversity, even if there are plenty of legitimate reasons for it. – eltiare Aug 28 '21 at 14:44
  • 2
    Blazor is a tool meant to replace JS with C#. Web Assembly is meant to run along side of JS, not replace it. Blazor would not be to C# and Web Assembly to what Emscripten is to C/C++ and Web Assembly. Also, Blazor advertises to write UI Components in C#. Google engineers state to not write your components in Web Assembly. – dman Dec 29 '21 at 03:09
  • I'd love to be able to write something like a sass compiler or typescript compiler in webassembly (ideally something performant like C#). yarn/npm is a great way to distribute command line tools, especially for the node ecosystem. – Clay Lenhart Jan 17 '22 at 18:33
  • 1
    @dman I agree with this, especially "Google engineers state to not write your components in Web Assembly." Blazor's biggest flaw is doing WAY too much performance-sensitive stuff, most notably DOM building and diffing, in the C# world then transferring it all over to JS through very inefficient interop. Thus Blazor apps with any significant complexity are not really usable, even after AOT. Building your UI natively and calling into C# as needed is currently the only viable approach if you expect people to actually use and pay for your app. Unfortunately MS doesn't officially support this. – Emperor Eto Jan 21 '22 at 13:33
  • @PanagiotisKanavos here's my question about why I don't wish to use Blazor https://stackoverflow.com/q/70474778/810328 – vcRobe Jun 09 '22 at 14:24
  • 1
    @vcRobe that doesn't explain the `why`. Quite often that's the **most** important question. When I asked `why` I had Electron apps in mind. Or maybe someone wanted to create Web components. Or just a transpiler that generates WASM from C# source. If there are 100 ways to do something, or 100 things to do with one thing, you really need to know what the actual problem is to be able to pick a solution or narrow down the options. – Panagiotis Kanavos Jun 09 '22 at 14:44
  • They just moved Mono WASM, it's not gone and has been "killed". I see people pushing to the repo regularly, as recent as a few hours ago, so it's definitely still around – Aaron Carter Dec 13 '22 at 20:06
  • 1
    @AaronCarter it seemed to be dead for a bit, with no documentation of where it was moved and Microsoft indicating that all development efforts were to be focused on Blazor. It seems since I asked this question that they have changed their minds. – eltiare Dec 26 '22 at 19:17
  • @eltiare totally understandable and I was just updating info, not criticizing you. I was just lucky to have stumbled upon that information as to its whereabouts and status and hoped it would be helpful. – Aaron Carter Feb 22 '23 at 23:03

4 Answers4

15

Yes it's absolutely possible. Blazor does not have a monopoly on C#/WASM and it's far from clear that it's going to wind up being the best long term option (and a lot of evidence it's not).

I recommend starting with the Uno WASM Bootstrap. https://github.com/unoplatform/Uno.Wasm.Bootstrap

2022-06-30 Edit - More evidence Blazor is not the only game in town nor even at the forefront of innovation here: https://visualstudiomagazine.com/articles/2022/06/29/uno-platform-4-4.aspx

Emperor Eto
  • 2,456
  • 2
  • 18
  • 32
  • 1
    I was really hoping that .NET 6 would just support this. But it looks like a good lead. Thank you. – eltiare Aug 27 '21 at 17:52
  • 6
    Yeah Microsoft doesn't seem to be interested in WASM except in the context of Blazor. Very strange and annoying that they killed the Mono SDK. Plus, despite a huge outpouring of support for a WASM/Web target for MAUI, they've stayed completely silent on it. It really is inexplicable. But the guy behind Uno is super smart and helpful and really believes in combining C#+WASM so he is very open to projects like this that don't use Blazor OR Uno. Follow his directions to the letter and you will be able to get it working I'm sure. – Emperor Eto Aug 27 '21 at 18:46
  • FYI, using the Uno Bootstrapper, I actually ported a huge portion of WPF to WASM. Unfortunately the performance wasn't acceptable, but it was a fun project. Point is there is a huge potential world out there for this beyond Blazor. – Emperor Eto Aug 27 '21 at 18:47
  • @PeterMoore I'd love to see that fork. I've been wondering if it was possible to port WPF to WASM myself. I was thinking that once AOT and WebGPU was implemented, we could port DXVK using Emscripten to WASM to replicated the DX GPU functionality. – Aron Sep 19 '21 at 17:13
  • @PeterMoore "Microsoft doesn't seem to be interested in WASM except in the context of Blazor" I don't think this is true. Check out Microsoft's work with Krustlet: https://krustlet.dev/, WAGI: https://github.com/deislabs/wagi, and Hippo: https://github.com/deislabs/hippo. Looking at that body of work, MSFT has a very different context for WASM. – Charles Chen Feb 01 '22 at 15:18
  • 1
    @CharlesChen All of those projects seem oriented around wasm used as servers/microservices, not wasm for in-browser js use. – Mike Asdf Mar 29 '22 at 20:59
  • @MikeAsdf absolutely right. I didn't want to shoot down the suggestions but it remains true that Microsoft's only investment in WASM from an application development perspective is Blazor. And basically killing the Mono WASM SDK really was a big and unnecessary blow to anyone looking for an alternative. – Emperor Eto Mar 30 '22 at 11:06
  • What about https://github.com/SteveSandersonMS/dotnet-wasi-sdk? – Marcos Pereira Jan 16 '23 at 00:48
  • Not familiar with WASI but with .NET 7 they have taken significant steps toward decoupling.NET WASM from Blazor, which I think is great. Excited to see what evolves from it. – Emperor Eto Jan 16 '23 at 15:28
6

It seems that dotnet 7 has improved WASM support. More information is provided in https://devblogs.microsoft.com/dotnet/dotnet-7-wasm/

Alireza
  • 5,421
  • 5
  • 34
  • 67
5

NativeAOT-LLVM, an experimental c# compiler not official supported by Microsoft, (https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM) can also compile C# to Wasm without any UI framework requirements. There's a similar question about libraries at Compiling C# project to WebAssembly

S Waye
  • 694
  • 1
  • 7
  • 12
5

The Mono WASM SDK is continued in the dotnet/runtime repo. The tooling based on old Packager.exe has evolved into a MSBuild/csproj based solution:

https://github.com/dotnet/runtime/tree/main/src/mono/wasm

samples: https://github.com/dotnet/runtime/tree/main/src/mono/sample/wasm

The key issue when I trying to use code in a custom project (not within the sample) is that we need to reference a private assembly System.Private.Runtime.InteropServices.JavaScript.dll which is included in Microsoft.NETCore.App.Runtime.browser-wasm. The code is almost the same as WebAssembly.Bindings.dll in old mono wasm sdk.

Here is a screenshot of a WebGL page I created, based on dotnet/runtime/mono/wasm: enter image description here

BTW there is a viewpoint that the performance of implementing WebGL via calling JavaScript functions from C#, is bad: https://marcoscobena.com/?i=wave-engine-web-performance

zwcloud
  • 4,546
  • 3
  • 40
  • 69
  • Nice find. DOM manipulation in WASM is going to be slow for the foreseeable future but plans are in the works to bring it up to par with JavaScript. – eltiare Jan 30 '22 at 16:06