Avalonia WebAssembly Support

dleberfinger · April 8, 2025, 12:07pm

I am planning to use Avalonia for a GUI based project, on an Ivy Carrier board and IMX8M Plus, but would ideally have a remote browser view available to the end user. Avalonia seems like a great fit due to the WASM version. I have already developed some applications that successfully deploy a Desktop and WASM version for Windows, but I was wondering if there was any information about doing this through Torizon and the Docker environment. It seems like it should be pretty straight forward, make the static files, host through nginx or something similar. Before I go down this road, I was wondering if anyone had experience with this or an example of how they structured their project to easily handle the transfer through VSCode to the board/docker deployment. Any hurdles I may face would also be useful. This application would have the potential to have multiple users at once.

eric.tx · April 9, 2025, 6:05pm

Hey @dleberfinger,

While I couldn’t find any developer documents with guidance for Avalonia, We do have two container templates available for Avalonia.

.NET C# Avalonia Frame Buffer DRM and .NET 8 C# Avalonia GTK MVVM

You can view the READMEs here.

github.com

toradex/vscode-torizon-templates-documentation/blob/main/dotnetAvalonia/README.md

# .NET6 C# Avalonia GTK MVVM template specific documentation

All projects follow the pipeline of tasks described in the [common contributing documentation](https://github.com/toradex/vscode-torizon-templates/blob/bookworm/CONTRIBUTING.md#contributing-templates). However, each project has its own specificities in terms of technologies and methods used to compile, deploy, and debug the code. Therefore, each of them has their own specific tasks in the **tasks.json** file.

This .NET C# Avalonia GTK MVVM template uses **dotnet publish** CLI command to compile the source code and create a deployable package, with tasks named **publish-torizon-\${architecture}**. However, for local debugging it is not necessary to create a deployable package so just the **dotnet build** task is enough in this case(please note that the **preLaunchTask** of local debug is **build-torizon-local** and not **publish-torizon-local**, but the publish local task is there just for you to use if for any specific reason you need this local publish).

For .NET templates it is important to point out that they do not use the torizon base containers (torizon/debian, torizon/wayland-base, torizon/wayland-base-vivante, etc). Instead, they use custom **dotnet**, **aspdotnet** and **dotnet-uno** containers, which are based on the base containers but also contain the appropriate .NET runtime (and debugger for debug images) and some necessary dependencies to execute the code. Therefore, the **--no-self-contained** argument can be passed to the **dotnet publish** command to not compile and ship also the .NET runtime to the remote container. This template uses the **dotnet-uno** containers as the base containers.

The deployable package is then copied into the running debug container using **scp**, in the task named **deploy-torizon-\${architecture}**. This task contains the entire sequence of tasks executed by the pipeline and, therefore, is unique to each template.

Finally, remote debugging is performed by attaching to the Visual Studio Debugger (vsdbg) on the running container on the device using a [VSCode feature called Pipe Transport](https://code.visualstudio.com/docs/cpp/pipe-transport). For local debugging, the method used is the one described in the [VSCode documentation for .NET Debugging](https://learn.microsoft.com/en-us/dotnet/core/tutorials/debugging-with-visual-studio-code?pivots=dotnet-6-0) is used. The tasks that perform the debugging are those present in the **launch.json** file.

The source code of the template is inspired by the one created following the [instructions from the Avalonia UI documentation](https://docs.avaloniaui.net/tutorials/todo-list-app/creating-a-new-project#net-core-cli), using the Avalonia .NET Core MVVM App template (avalonia.mvvm).

dleberfinger · April 9, 2025, 6:33pm

Hello @eric.tx

Thank you for the response. I am aware of these and have tested them for another project we have in the pipeline, but these are more focused for a device that needs a local display. The project in question currently does not have its own screen, but instead hosts a web server to display the program through a WiFi/LAN connection. Ultimately for this I think I will start with one of these and hack out all the local visualization related items or just start from a blank project. Not sure what the best approach is there yet.

leon.tx · April 9, 2025, 7:35pm

Hello,

It seems like it should be pretty straight forward, make the static files, host through nginx or something similar

but instead hosts a web server to display the program through a WiFi/LAN connection

I’ve done this several times in other projects and should be a good, well-tested path. You can run these services from the container and expose a port. Then you can point browsers to the local IP+port combo of the board which will be routed to the container.

It’s particularly nice from a container because it gives you a lot of control over the service isolation. You can use the generic template from the IDE extension as a starting point.

We’ve done some internal experiments with Wasm, but I would recommend against deploying in production at the moment, the whole ecosystem needs to mature a bit more for embedded.

dleberfinger · April 9, 2025, 7:38pm

Hello @leon.tx,

Are there any specific concerns you have about using WASM for embedded applications? I’d love to hear more about why you have that recommendation, there are a few big benefits for us to use Avalonia for this project.

leon.tx · April 9, 2025, 7:57pm

Hey David,

Let me try to understand your use-case a bit better.

If I understood correctly, Avalonia will get you a wasm bundle that can be served from an HTTP server and you need some way to server those files statically. If that is your use-case, I think you’re good to use wasm; it would be quite reliable although you might want to check browser-compatibility before you deploy this on the field.

However, if you want to run wasm from the device itself, which maybe bundles the http server and everything else, that’s where I’d recommend against because you’d need to do some custom work.

With Wasm on Embedded we can either use a runtime like wasmer for example, would require a Yocto build [0] or use the Wasm Workloads features on Docker Wasm workloads | Docker Docs which is not available on Torizon, so again you would probably need some custom work.

Did I get it somewhat right?

[0] if you want to explore that route, I have published recipes for the Wasmer runtime Wasmer Yocto Recipe ($4827543) · Snippets · GitLab. Note that this is not supported by Toradex at all, it was done for internal experimentation only.

dleberfinger · April 9, 2025, 8:01pm

Leon,

I think you’ve got it with the first description. Our project would build the static files and those would be transferred to the board to be served by the web server.

From a brief look into Wasmer, I don’t think that is something we have any intent to do. We would deploy Avalonia directly on the board through the framebuffer Torizon template if we need it to run on a local display or server the .Browser output from the Avalonia cross platform project if we need to display it over the web.

Assuming I can trust CanIUse, it looks like browser compatibility shouldn’t be much of a concern for me.

leon.tx · April 10, 2025, 12:49pm

Hey again David,

Assuming I can trust CanIUse, it looks like browser compatibility shouldn’t be much of a concern for me.

Then it makes total sense to go for it, it seems like a good architecture. For the HTTP server, I suggest you to evaluate between the most common ones like nginx, httpd, lighthttpd, caddy etc. Most of them should have officlal Docker images, too. Load-testing each server is also a good idea depending on how many connections you’ll make to the device.

I consulted internally and we don’t have any deployment guides in particular, but the official docs for the selected server should be sufficient.

Let us know if you have further questions.