Add AvaloniaView for WinUI

[juwens]

Is your feature request related to a problem? Please describe.
Fer a gradual migration of WinUI/MAUI-Windows it‘s necessary to have a AvaloniaView which can be placed anywhere in the app an renders ava, like you did in the sample AvaloniaMauiHybrid for Android and iOS.

The body (without page layout, burger menu, etc) of new developed page in our LOB application, would be written in Ava, and then inserted as AvaloniaView in an existing WunUi/MAUI Page Layout.

Then, when there‘s the need to refactor an old page, rewrite it to Avalonia.

When everything else is done: replace the surrounding page-Layout with avalonia.
This might take 24 months. We cannot shut our app down during this kind of migration.

Describe the solution you'd like
An AvaloniaView like on every other platform (iOS, Android, Blazor, etc.)

Describe alternatives you've considered
At the moment, I try to solve it myself. But in the end it would be a NO for adopting/subscribing avalonia. The alternative we consider is MauiBlazorHybrid.

Additional context
It’s essentially a feature request, to get something like this working: AvaloniaUI/AvaloniaMauiHybrid#7

[kekekeks]

How well does WinUI interop with Win32? Do they share the event loop? If so, a WinUI-based view class could live side-by-side with our normal Win32 backend and share the rest of the services like clipboard, GPU support and other stuff.

[juwens]

@kekekeks since the death of UWP, all apps are Win32 apps.

What's noteworthy about UWP, WinUI, WinRT, WindowsAppSDK stuff:
UWP consisted of three things.

1. the UI Layer, which is now WinUI 3 (they essentially forked the UWP controls)
2. the OS API called WinRT (Windows Runtime) for FileIO, NetIO, MSIX, etc.. It still exists, but you call all of it from a Win32 app. It's WindowsAppSDK minus WinUI3.
3. the UWP .Net Runtime, this is the only thing which is completely dead

To summarize: everything is Win32 now, except when you explicitly call WinRT APIs. The UI is a special case of course.

The WinUI controls are COM classes (but you in you daily dev job, don't see any of this) and the real UI lives in native code behind the COM abstraction (but again, when you write your you UI you don't see any of this, you only work with managed classes and visual tree).

call-stack of an WinUI app-launch

App.dll!App.App.App() Line 35	C#
App.dll!App.Program.Main.AnonymousMethod__1_0(Microsoft.UI.Xaml.ApplicationInitializationCallbackParams p) Line 34	C#
Microsoft.WinUI.dll!ABI.Microsoft.UI.Xaml.ApplicationInitializationCallback.Do_Abi_Invoke(System.IntPtr thisPtr, System.IntPtr p)	Unknown
[Native to Managed Transition]	
Microsoft.ui.xaml.dll!52829dae()	Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for Microsoft.ui.xaml.dll]	
Microsoft.ui.xaml.dll!52799fd4()	Unknown
[Managed to Native Transition]	
Microsoft.WinUI.dll!ABI.Microsoft.UI.Xaml.IApplicationStaticsMethods.Start(WinRT.IObjectReference _obj, Microsoft.UI.Xaml.ApplicationInitializationCallback callback)	Unknown
Microsoft.WinUI.dll!Microsoft.UI.Xaml.Application.Start(Microsoft.UI.Xaml.ApplicationInitializationCallback callback)	Unknown
App.dll!App.Program.Main(string[] args) Line 31	C#

This might be interesting:

• Custom message loop and WinMain in WinUI 3? microsoft/microsoft-ui-xaml#4160
• add in your csproj DISABLE_XAML_GENERATED_MAIN=true and you can intersect to bootstrapping of the otherwise generated code

default generated bootstrapping code without DISABLE_XAML_GENERATED_MAIN=true

#if !DISABLE_XAML_GENERATED_MAIN
public static class Program
{
    [System.Runtime.InteropServices.DllImport("Microsoft.ui.xaml.dll")]
    private static extern void XamlCheckProcessRequirements();

    [System.STAThread]
    static void Main(string[] args)
    {
        XamlCheckProcessRequirements();

        WinRT.ComWrappersSupport.InitializeComWrappers();
        Microsoft.UI.Xaml.Application.Start((ApplicationInitializationCallbackParams p) =>
        {
            Microsoft.UI.Dispatching.DispatcherQueue dispatcherQueue = Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread();
            var context = new Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext(dispatcherQueue);
            System.Threading.SynchronizationContext.SetSynchronizationContext(context);
            new App();
        });
    }
#endif

If I'm (from my level) interpreting this correct, these two lines are the most interesting. One COULD

Microsoft.UI.Dispatching.DispatcherQueue dispatcherQueue = Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread();
var context = new Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext(dispatcherQueue);
System.Threading.SynchronizationContext.SetSynchronizationContext(context);

[kekekeks]

Do they still use that "Only one thread per window" model?
If everything lives in main UI thread and if they have a proper event loop, it should be compatible with our dispatcher

[juwens]

@kekekeks sorry, IDK if they use "Only one thread per window".

But after letting all the infos sink in, i now understand why it wasn't done yet.

Fun fact, with recently released App SDK, they added the inverse API.
You can now host WinUI3 Controls in Winforms and WPF. But that's not, what we are waiting for (HWND in WinUI3).

I guess, if one is determined, one could do things like putting an empty placeholder in your WinUI Layout, and then in the Win32 App render an Avalonia Control at this postion over the .