Native Avalonia Controls with NativeAOT.

[josephmoresena]

I would like to know if this scenario could be supported by Avalonia UI now that NativeAOT is a non-experimental implementation within the .NET ecosystem.

Let's imagine I have an application using Avalonia UI built with NativeAOT. This application could be considered a launcher (Windows) for different screens (User controls) distributed across various modules. The lifecycle of each module is distinct, and I would like to manage the maintenance of the application according to the module (the launcher itself being another module).

Is it possible to create libraries with NativeAOT that somehow allow linking Avalonia controls compiled in the native library, but which interact with the managed environment created by the main Avalonia UI instance that would be instantiated by the launcher?

[kekekeks]

NativeAOT doesn't support:

1. dynamically linking NAOT-ed code from multiple modules
2. loading external .NET libraries
3. having multiple .NET runtimes (read: NAOTed .net dlls) in the same process

If you need to load .NET code dynamically you need to use non-AOT runtime

[josephmoresena]

Hi @kekekeks, these points are clear to me, except for the third one. It's possible to load multiple NAOT dynamic libraries in the same process, each running its own runtime/environment. Any interaction between them should be done via FFI.

For example, within the same main process, you can launch multiple ApplicationHosts in different threads that exist in separate NAOT libraries. (Of course, some additional configurations regarding console interaction and other aspects are required.)

Regarding the second point, what I mentioned does not involve loading external .NET libraries, everything should be known statically. The only 'special thing' is that the user control runs in another runtime; for Avalonia, it behaves like a native control. Perhaps the only dynamic aspect might be the path and name of the library that implements the control, to avoid using the DllImportAttribute approach and instead use the approach provided by the NativeLibrary class.

As for the first point, I don't think that's what I'm talking about. I recall when NAOT was still an experiment (CoreRT) there was a 'multi-lib' compilation, but they shared the same runtime. This is not desired.

The scenario I'm imagining is: one process (main process) initializes the Avalonia application instance. Through FFI, this app instance can interact with Avalonia components within shared native libraries (which will be running isolated from the application runtime, similar to unmanaged components).

The user controls could be instantiated by any window created by the main process, regardless of which module they belong to.
Visually, they will appear as a unified set (they run at the same process but not at the same environment), but all interaction will occur through FFI. Perhaps some events, like drag and drop, might not be supported, but generally, they would only be running in the same 'visual' space (same UI thread?). Would that be possible?

[kekekeks]

You can try using RemoteServer/RemoteWidget with some custom in-memory transport. Those are driving our previewer.