Creating WinUI3 window from WPF window

[teh173]

I'm trying to simply do the following:

1. Have an unpackaged WPF app referencing WinUI3
   (following this
   https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/use-windows-app-sdk-in-existing-project
   https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/use-windows-app-sdk-run-time

2. Create and show a WinUI3 window from WPF

A. I assume XAML islands (embedding inside a WPF window) for WinUI 3 is still being developed.

B. If XAML islands isn't available, can I simply create a new Microsoft.UI.Xaml.Window from a WPF System.Windows.Window? How do I do this with WinUI3 XAML in a class library (not application)? Am I missing initializing something? Whenever I create a window (or application) I get an error, "The application called an interface that was marshalled for a different thread." I've tried various things involving creating a DispatcherQueue, but it hasn't helped...

C. I assume there's no compiler magic trick to including WPF/.NET6/Microsoft.WindowsDesktop.App and Microsoft.WindowsAppSDK XAML windows in the same project. (When I tried that, compiling a WinUI3 XAML window tried to generate a .g.cs for a WPF window instead.)

[DarranRowe]

Unfortunately, Microsoft.UI.Xaml.Application or WindowsXamlManager is required since it works as a controller for Xaml. This means that without Xaml Islands, you have to have a fully functioning Application object. This includes the Xaml metadata provider. Also, with my experiments with Xaml Islands, "marshalled for a different thread" can also mean that a dispatcher queue doesn't exist for the UI thread.
I honestly haven't experimented with a class derived from Microsoft.UI.Xaml.Window outside of the Application's Start static function. If Application just needs to exist and you have to pump the message queue then you could get away with it, but that is very unsupported.
Also, Xaml Islands for WinUI 3 is currently only available in the experimental versions. So right now that is 1.2 experimental 1.

[DarranRowe]

After messing around with this a little, Application.Start is required for things to work correctly. But for the Windows App SDK, this has the side effect of starting a message pump.
Using the WinUI 3 WindowsXamlManager from the experimental 1.2, I can get it to go part way towards running, but this still doesn't allow the creation of a window derived from Microsoft.UI.Xaml.Window. So Start seems to do quite a bit under the surface.
So yeah, it seems like there is no good way to do this now.

[teh173]

I'm using 1.2.220727.1-experimental1.

I was able to create an Application class. The required code is generated in App.g.i.cs for an App.xaml object, but is not called in a class library:

    public static class Program
    {
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.UI.Xaml.Markup.Compiler"," 1.0.0.0")]
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
        static void Main(string[] args)
        {
            global::WinRT.ComWrappersSupport.InitializeComWrappers();
            global::Microsoft.UI.Xaml.Application.Start((p) => {
                var context = new global::Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext(global::Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread());
                global::System.Threading.SynchronizationContext.SetSynchronizationContext(context);
                new App();
            });
        }
    }

• For some reason, calling this immediately from the WPF Application startup hangs, so I had to defer calling it, and then it seems to work. With that, creating XAML windows now works

         XamlCheckProcessRequirements();
         global::WinRT.ComWrappersSupport.InitializeComWrappers();
         Dispatcher.BeginInvoke( DispatcherPriority.Normal, (Action)( () =>
         {
            global::Microsoft.UI.Xaml.Application.Start( ( p ) => {
               var context = new global::Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext(global::Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread());
               global::System.Threading.SynchronizationContext.SetSynchronizationContext( context );
               _uiApp = new WinUIApp.App();
            } );
         } ) );

• I can keep on opening WinUI XAML windows. But after closing the last WinUI XAML window, it seems to uninitialize something, breaking opening any more windows (Microsoft.UI.Xaml.Application.Current still seems to be valid). Not sure how to work around that. WPF had a https://docs.microsoft.com/en-us/dotnet/api/system.windows.shutdownmode to keep the application object running.

At this point if I were using WPF, I'd try to look at the https://referencesource.microsoft.com/ or github to try to understand what's happening, but unless I'm not finding it, WinUI3/AppSDK is even less "open source" than WPF was... only some of higher level components are open source, not things like Window or Application.

This seems like a very basic interop scenario 😑

[teh173]

Just realized I had cleared out my App.xaml from the default in order to get it to work.... If I restore the default App.xaml, or if I do something semi-complicated in the XAML for the Window, like add a CanvasControl from another namespace to XAML (Win2D)... a XAML Parse exception is thrown.

<Application
    x:Class="App1.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App1">
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" />
                <!-- Other merged dictionaries here -->
            </ResourceDictionary.MergedDictionaries>
            <!-- Other app resources here -->
        </ResourceDictionary>
    </Application.Resources>
</Application>

So, obviously something else needs to get initialized for XAML to function properly... WindowsXamlManager.InitializeForCurrentThread doesn't seem to help..

[DarranRowe]

The issue is that UWP Xaml/WinUI 3 and WPF try to completely control things. It is part of that making things simpler removes more advanced options things.
From C++, I have had a lot of progress. I had an epiphany after having a decent night's sleep. There were two major facts that I realised. First, applications don't have to be single threaded. Second, you don't have to have only a single UI thread.
I overrode main, created a second thread and then called Microsoft.UI.Xaml.Application.Start. The second thread had a message pump going and it was working without issue. There was a little bit of house keeping that needed to happen, and I think you would really need to keep a blank WinUI 3 created but hidden to stop the Application instance from closing before you wanted it.
However, I'm not sure how this would interact with WPF. WPF doesn't allow you to override Main, there is also the potential conflict with two instances of App.xaml.

[teh173]

The Startup Main object can be customized in the WPF project settings, I think...

I'm guessing the fact that a class library does not auto-generate a XamlTypeInfo.g.cs (see bottom of this page https://jaylee.org/archive/2012/03/08/xaml-integration-with-winrt-and-the-ixamlmetadataprovider-interface.html) when there is no corresponding XAML App project by which to generate it (just a WPF project), is also contributing to the fact that I can only get the most basic XAML working... Seems like a tool design issue.

Will "experimental" XAML islands work solve it? (without a lot of manual work arounds)?

Is it even being actively worked on?
https://portal.productboard.com/winappsdk/1-windows-app-sdk/c/9-xaml-islands-use-winui-3-from-wpf-or-winforms
Is XAML islands going to offer 3rd party support without requiring source code? (like the last time I looked at it a few years ago, when it was UWP islands)
So many different places to look for the current truth...

[DarranRowe]

First of all, considering everything, I doubt that there will be much difference between the UWP Xaml Islands and the WinUI 3 Xaml Islands.
The purpose of Xaml Islands is to load Xaml content into an existing window. Because the Xaml compiler isn't involved, you have to hook things up manually. But that was expected.
Also, I didn't find it too hard to get a WPF Xaml and a WinUI Xaml window existing together. As should be expected, you need to have two threads, one that has an instance of a class derived from System.Windows.Application which controls the WPF Xaml window, and the other has an instance of a class derived from Microsoft.UI.Xaml.Application to control the WinUI Xaml window. Once you realise that you have to use separate Application classes, it actually becomes rather easy.