Developers can AOT compile .NET apps into WebAssembly format

[marek-safar]

As more applications target .Net in the Browser there is a growing demand to support workloads that require additional performance. The .NET5 browser-wasm runtime supports only interpreted mode and can considerably underperform in performance-sensitive code paths. Large performance gains can be realized by compiling the code ahead of time (AOT) rather than interpreting it.

Performance, size, and other considerations dictate that the AOT compilation step should run after assemblies have been aggressively trimmed. This will require that additional tooling be installed on the developer's machine when targeting AOT, including native and managed cross compilers appropriate for their host environment (emscripten SDK and mono AOT).

AOT compilation also typically generates much less compact code than the original IL. To avoid prohibitively large assets, we will likely need to offer a mode of operation where performance critical code is AOT compiled and the remaining code is interpreted.

Work Items

• Common Tooling [P0]
  • Build tasks for AOT publishing
  • Workload pack for AOT cross compilers (Windows and macOS)
  • Workload pack for AOT tasks and msbuild integration
  • Workload pack for emscripten tooling
• Full AOT mode [P0]
  • Exception filters handling in WebAssembly AOT Exception filters handling in WebAssembly AOT #46927
  • Unmanaged Callers Only fixes
  • Native dependencies linking
• Mixed (+PGO) mode [P1] - CUT from .NET 6
  • Profile generation and editing
  • Produce and consume Wasm AOT profiles
  • Tooling to tweak the profiles (aprofutil)
• Testing [P0]
  • Reducing Managed Libraries Testing Infrastructure Size Reducing Managed Libraries Testing Infrastructure Size #45126
  • Passing Libraries Tests
  • Passing Runtime Tests [Mono] Tracking runtime test failures on Mono Interpreter backed WASM #44663
  • Add Blazor Functional Tests Convert MonoVM Samples into Functional Tests #43865
• Integrate AoT with Blazor [P0] Blazor WebAssembly AOT compilation aspnetcore#5466

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

[baktun14]

Is it possible compile a .net library to WebAssembly without blazor?

[jeromelaban]

@mbeauchamp7 what do you intend to do with it ? (e.g. Make an NPM package out of it)

[ChristianWeyer]

Is it possible compile a .net library to WebAssembly without blazor?

Have you seen this?
https://github.com/unoplatform/Uno.Wasm.Bootstrap

[baktun14]

Is it possible compile a .net library to WebAssembly without blazor?

I want to reuse some logic done in c# but in the browser. I would like to have a static .wasm file that I can simply load with an http request and communicate with it's exposed methods afterwards, something like sql.js is doing.

Have you seen this?
https://github.com/unoplatform/Uno.Wasm.Bootstrap

Yes I tried to use it but didn't seem very stable and was getting compilation errors.

[jeromelaban]

@mbeauchamp7 it's not yet possible to create a single wasm file at this point, because of the way emscripten works. There's also a bit packaging work that is needed to be done in the .NET side.

As for the uno.wasm.bootstrap package, I'm the author and I'm interested in the errors you got. If you have a chance, can you open an issue with your errors ?

[baktun14]

@jeromelaban Thanks for the info, I will try to reproduce the errors as I did get it to compile properly in visual studio. The errors I got was when I started, I was reading an older blog post that was setting an older version of the nuget package (1.1.0-dev.426) and building it with the command line, it was saying something along the lines of "WSL missing something something"... Anyways now it's compiling with version 2.0.0-dev.69(nice)!

[legistek]

Is it possible compile a .net library to WebAssembly without blazor?

I would definitely use Uno Bootstrapper but just note that even today without AOT you can make an interpreted Mono WASM project using the Blazor template, Blazor bootstrapper and Javascript interop without actually making a full blown Blazor app. Just get rid of everything in Program.Main and do your own thing. So it certainly should be possible with AOT also, but your final compiled WASM might be unnecessarily bloated.

[ChristianWeyer]

Is it possible compile a .net library to WebAssembly without blazor?

I would definitely use Uno Bootstrapper but just note that even today without AOT you can make an interpreted Mono WASM project using the Blazor template, Blazor bootstrapper and Javascript interop without actually making a full blown Blazor app. Just get rid of everything in Program.Main and do your own thing. So it certainly should be possible with AOT also, but your final compiled WASM might be unnecessarily bloated.

Interesting. Would you have a simple sample of this available?
Thanks.

[legistek]

Interesting. Would you have a simple sample of this available?

I don't, but just create a Blazor app using the default template, and then remove everything from Program.Main and do your own thing.

In index.html just make sure you keep
<script src="_framework/blazor.webassembly.js"></script>

Just note that you won't be able to use Blazor's Javascript interop classes directly because they depend on injection and the stuff you need is all internal.

Instead you can easily cannibalize from the Blazor source code, e.g., https://github.com/dotnet/aspnetcore/blob/52eff90fbcfca39b7eb58baad597df6a99a542b0/src/Components/WebAssembly/JSInterop/src/InternalCalls.cs#L13.

[microhobby]

It would be really cool to be able to compile .NET console application to WASI

[h3x4d3c1m4l]

At the moment, we have a situation where we might want to generate PDF reports using WebAssembly. Specifically WebAssembly as that seems to be the easiest way of integrating .NET in our existing solution.

We already found the PDF generation library we are familiar with to be working perfectly fine in AoT compiled Blazor. It runs even faster than we expected beforehand and even with minimal code changes.

For this specific situation it would be optimal if we could convert our Blazor PoC to a wasm library that can be run by a CLI based runner (for testing) or a WASM runtime library (for production). It does seem almost all parts of this puzzle are there already, it just seems there is currently no convenient way to compile a .NET console app or .NET library to WASM. It could be incredible helpful functionality to be able to use .NET in more platforms using WASM

There are native solutions which we could use for PDF report generation, but this specific .NET/WASM solution would be almost optimal for us in terms of code sharing between platforms and solutions and utilizing technologies we are already very familiar with.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As more applications target .Net in the Browser there is a growing demand to support workloads that require additional performance. The .NET5 browser-wasm runtime supports only interpreted mode and can considerably underperform in performance-sensitive code paths. Large performance gains can be realized by compiling the code ahead of time (AOT) rather than interpreting it.

Performance, size, and other considerations dictate that the AOT compilation step should run after assemblies have been aggressively trimmed. This will require that additional tooling be installed on the developer's machine when targeting AOT, including native and managed cross compilers appropriate for their host environment (emscripten SDK and mono AOT).

AOT compilation also typically generates much less compact code than the original IL. To avoid prohibitively large assets, we will likely need to offer a mode of operation where performance critical code is AOT compiled and the remaining code is interpreted.

Work Items

• Common Tooling [P0]
  • Build tasks for AOT publishing
  • Workload pack for AOT cross compilers (Windows and macOS)
  • Workload pack for AOT tasks and msbuild integration
  • Workload pack for emscripten tooling
• Full AOT mode [P0]
  • Exception filters handling in WebAssembly AOT Exception filters handling in WebAssembly AOT #46927
  • Unmanaged Callers Only fixes
  • Native dependencies linking
• Mixed (+PGO) mode [P1]
  • Profile generation and editing
  • Produce and consume Wasm AOT profiles
  • Tooling to tweak the profiles (aprofutil)
• Testing [P0]
  • Reducing Managed Libraries Testing Infrastructure Size Reducing Managed Libraries Testing Infrastructure Size #45126
  • Passing Libraries Tests
  • Passing Runtime Tests [Mono] Tracking runtime test failures on Mono Interpreter backed WASM #44663
  • Add Blazor Functional Tests Convert MonoVM Samples into Functional Tests #43865
• Integrate AoT with Blazor [P0] Blazor WebAssembly AOT compilation aspnetcore#5466

Author:	marek-safar
Assignees:	lewing
Labels:	arch-wasm, area-Meta, User Story, Priority:0, Cost:XL
Milestone:	6.0.0

[charlesroddie]

This issue Blazor AOT .Net6 Preview 7 - Still downloading Dlls suggests that full AOT is not complete and that what is currently called AOT by blazor is a mixed-mode AOT.

[bilalchraibi]

@danroth27 Since this user story is marked as completed, do you have any preliminary documentation that we can have use to get started?

[danroth27]

@bilalchraibi We have some initial docs here: https://docs.microsoft.com/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-6.0#ahead-of-time-aot-compilation

[bilalchraibi]

@danroth27 Thank you!