Uno Platform Claims First with WebAssembly AOT Compilation in Visual Studio

• By David Ramel
• 02/06/2020

Uno Platform claimed an industry first and addressed a "long-time request" by announcing the capability to build WebAssembly apps in Visual Studio on Windows using Ahead of Time (AOT) compilation.

"Visual Studio developers can get a head start on WebAssembly -- a key industry development -- and they can start building better-performant WebAssembly applications today," CTO Jérôme Laban told Visual Studio Magazine when asked how the news affects developers using Visual Studio. "Developers using Uno Platform and Visual Studio via the Uno WebAssembly Bootstrapper, can create fully Ahead of Time (AOT) compiled packages directly from Visual Studio, without jumping through the hoops of command line with Windows Subsystem for Linux (WSL) which is not a trivial task at all."

Specifically, Uno announced the ability to create optional builds on Windows 10 -- AOT, Mixed (AOT+Interpreter) and Interpreter (with Bitcode dependencies) -- within Visual Studio 2019 as part of a new Uno.Wasm.BootStrap package in the project's dev branch.

Uno Platform helps .NET developers build single-codebase, cross-platform web, mobile and desktop apps. While iOS and Android mobile apps leverage Xamarin Native technology, WebAssembly apps created with the Uno Platform are based on the Mono-Wasm runtime. All of these things are related, as Xamarin is based on the Mono project, an open-source port of the .NET framework. It is most commonly used to run .NET under Linux.

"Uno Platform is, to our knowledge, the only user of mono-wasm AOT engine, and at this point, it can only be used on a Linux-compatible system. What we're doing is using Windows Subsystem for Linux (WSL) to work around that limitation and allow developers to build AOTed applications from Visual Studio today," Laban told VSM.

The new AOT capability lets Uno replace a dynamic linking workaround the team had to use previously. "This requirement is caused by the inability of the mono-wasm SDK to run on natively on Windows to do static linking (referencing an LLVM '.bc' bitcode file)," Laban said in a Feb. 6 blog post. "This prevented developers using Visual Studio on Windows to build applications that make use of either AOT or that reference those libraries.

"The deciding factor for enabling Windows support is the inability to use dynamic linking (the ability to reference '.wasm' files, through P/Invoke in mono) properly since the LLVM backend has been enabled in emscripten (1.39.1 and later). A chain of issues has made this process fragile and very difficult to work with. This also prevented the use of libraries such as libSkia or SQLite."

The ability to use AOT had been available for a while, but a new boostrapper eases that "out-of-band" process that is now rendered transparent by the bootstrapper and some provided scripts.

Microsoft is also addressing AOT in its red-hot Blazor project, which puts WebAssembly to use to provide a compilation target for C# in web development, obviating the need to use the nearly ubiquitous JavaScript programming language. Blazor comprises a server-side component called Blazor Server and a client-side counterpart called Blazor WebAssembly. In announcing the unified .NET 5 framework that will debut later this year, Microsoft last year said, "While most .NET 5 workloads will use the existing just-in-time compiler (JIT), ahead-of-time (AOT) native compilation will be used for iOS and client-side Blazor (based on WebAssembly)."

In fact, the client-side Blazor WebAssembly development effort trailed the server-side component and wasn't ready for .NET Core 3.0, partially due to Mono, WebAssembly and AOT considerations. As Blazor expert Chris Sainty said one year ago, "The simple fact is that the client-side model relies not only on WebAssembly but also the efforts of the Mono team and their WASM .NET runtime. While progress is being made extremely quickly it's not quite there yet. AOT is not an option, there is extremely limited debugging, performance needs to be improved, download sizes are too big, etc."

Today's announcement and other recent developments show just how much progress has been made in addressing those issues in one year, though Microsoft hasn't announced any similar breakthroughs lately and is aiming for AOT support in .NET 5 -- which is debuting in November -- rather than with the expected unveiling of Blazor WebAssembly in May.

"Microsoft hasn't made any public announcements about official availability, other that the fact they are working on mono AOT for Blazor," Laban told VSM. "From Daniel Roth's response on GitHub it looks like the support will not be available for the May Blazor release. In May Blazor will ship with an IL interpreter-based runtime." That referenced AOT compilation issue raised in the ASP.NET Core repo was opened by Roth on Jan. 25, 2018.

In the meantime, Laban has high hopes for the technology being spearheaded by Uno Platform. "While not apples-to-apples comparison, previous, similar, bench-marking efforts on Interpreted vs AOT modes have shown AOT to be faster to the order of magnitude compared to Interpreted mode -- i.e. https://medium.com/wasmer/benchmarking-webassembly-runtimes-18497ce0d76e" Laban told VSM. "Our own benchmarking shows that using .NET AOT compilation gives a 40x improvement over the interpreter."

Documentation for Uno.Wasm.Bootstrap and its static linking functionality is provided on GitHub.