Place WinUI 3 controll in XAML of WPF (.NET 6)

[LunevNF]

Hi. Can you please tell me if it is possible to place a control (winUI 3) inside a Window or UserControl (WPF, .NET 6)?
Xaml Island not working because of difference betwen Platforms (runtime error).
If it possible, please help to do it :)

[LunevNF]

Maybe it possible using hwnd? (HwndSource.FromVisual...)

[LunevNF]

Or Visual Layer?

[DarranRowe]

Currently, the WinUI 3 hosting API is experimental only.
What you want is in the Windows.UI.Content namespace of the experimental releases only. This is not supported in the current releases.

[LunevNF]

Currently, the WinUI 3 hosting API is experimental only. What you want is in the Windows.UI.Content namespace of the experimental releases only. This is not supported in the current releases.

Thanks, but I cannot find any tutorial in official github or learn.microsoft.com
Can u explain, how to use ContentIsland for resolve my problem?

[LunevNF]

I already try to add namespace insdie xaml (Microsoft.UI.Content) - not found any controls.
As I understand, it must work like Windows.Tools....XamlHost

[DarranRowe]

Well, they don't document experimental APIs, which is a pain.
But yes, it is a hosting API, so you would expect it to work along the same lines of the inbuilt Xaml hosting functionality.

[ghord]

There were mentions in community call that we are getting those APIs stable in 1.3.
Are there any docs on how to use them?

[DarranRowe]

No official documentation, because they were not made stable in 1.3, and they are still not stable in 1.4.
As an example, using winmdidl.exe to extract the list of interfaces and runtime classes in Microsoft.UI.Xaml.winmd for 1.4-experimental 1, you can find:

[composable(Microsoft.UI.Xaml.Hosting.IDesktopWindowXamlSourceFactory, public, Microsoft.UI.Xaml.Hosting.HostingContract, 1.0)]
[contract(Microsoft.UI.Xaml.Hosting.HostingContract, 1.0)]
[experimental]
[marshaling_behavior(agile)]
[threading(both)]
runtimeclass DesktopWindowXamlSource
{
    [default] [experimental] interface Microsoft.UI.Xaml.Hosting.IDesktopWindowXamlSource;
    [contract(Microsoft.UI.Xaml.Hosting.HostingContract, 1.0)] [experimental] interface Windows.Foundation.IClosable;
}

This is in the Microsoft.UI.Xaml.Hosting namespace. Most of that isn't really interesting, but the big important thing is the experimental attribute. If you look in 1.4-preview 1, the only runtime class in the Microsoft.UI.Xaml.Hosting namespace is ElementCompositionPreview. You can use ildisasm on the .winmd files too, since these files just use the .NET metadata format.
Microsoft.UI.Content is the same, everything in that namespace is marked as experimental in 1.4-experimental 1, and hence doesn't exist in 1.4-preview 1. So unless there is a second round of experimental/preview releases for 1.4 which makes hosting stable, I would be surprised if the hosting API ends up suddenly being stable in 1.4 release.
Anyway, the official documentation will always be found on learn. The thing to remember is that when you are looking at the documentation page for anything, there is a dropdown to the side which allows you to select the version you want. I have not looked for anything unofficial though.
Although, it looks like DesktopWindowXamlSource is the starting point.

[ghord]

Yeah, I got those versions mixed up, but in the June community call at 12 minute mark it was mentioned that Islands API will be stable in 1.4. Is this different set of APIs?

[DarranRowe]

If anything, this is a statement of "the Xaml hosting API is currently marked as experimental".
There could be a second experimental and/or preview release for 1.4. In fact, microsoft/microsoft-ui-xaml#8638 states that they are "putting finishing touches on 1.4 Preview 2". While it would be questionable form for this to release with the hosting API finalised without a corresponding experimental version to make it stable, it is very possible that preview 2 could make the hosting API stable.
This is something that is in the future, but the hosting API currently being marked as experimental doesn't mean that it can't be made stable for the 1.4 release.

[DarranRowe]

To bump this, 1.4 Preview 2 silently released recently.
This version contains the hosting API in Microsoft.UI.Xaml.Hosting, but the documentation hasn't been updated yet. For this, keep an eye on the hosting documentation for 1.4. I would imagine that this will be updated to reflect the Preview 2 release soon, and it will be updated when 1.4 is released properly.
The release notes for this version can be found here.

[DarranRowe]

After messing around with this for a little, I found that, for simple cases, sticking to the template for the Windows Xaml Islands isn't a bad idea. There are a couple of changes needed though.

1. You need to create a dispatcher queue from the namespace Microsoft.UI.Dispatching prior to working with the Windows App SDK version. It doesn't do it automatically and trying to initialise Xaml hosting using Microsoft.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread will fail (and the projection will throw an exception) without the dispatcher queue.

2. It uses a Microsoft.UI.WindowId to identify a window, rather than a HWND. This means that the interop interfaces are no longer used. To attach a Microsoft.UI.Xaml.Hosting.DesktopWindowXamlSource to a window, you now use DesktopWindowXamlSource.Initialize and pass in a window id. This is equivalent to IDesktopWindowXamlSourceNative::AttachToWindow.
   To obtain a handle to the content, you would first use DesktopWindowXamlSource.SiteBridge to obtain an instance of Microsoft.UI.Content.ChildSiteBridge, then you would use ChildSiteBridge.WindowId to get the associated window. This is equivalent to IDesktopWindowXamlSourceNative::get_WindowHandle.
   The conversion between HWND and WindowId can be done using Microsoft.UI.GetWindowIdFromWindow and Microsoft.UI.GetWindowFromWindowId.

3. It looks like the Windows App SDK keeps track of the individual DesktopWindowXamlSource instances internally. The Windows' version didn't do this, so you needed to obtain the IDesktopWindowXamlSourceNative2 interface and then use IDesktopWindowXamlSourceNative2::PreTranslateMessage. The Windows App SDK has a single ContentPreTranslateMessage function that is exported from Microsoft.UI.Windowing.Core.dll. This seems to do all of the work that you used to have to do via the IDesktopWindowXamlSourceNative2 interface for each instance of DesktopWindowXamlSource before. Just be aware that it is a good idea to set Microsoft.UI.Windowing.Core.dll as delay load, or use LoadLibrary/GetProcAddress to obtain a pointer to it in a C++ application. This is especially true if you are framework dependent.

4. Using a class derived from Microsoft.UI.Xaml.Application is still needed for the metadata. Because of the namespace differences Microsoft.Toolkit.Win32.UI.XamlApplication is unusable. You can use the source for that or Alexander Sklar's as a base for your own version.

Finally, there is a whole load of C++ stuff here. I haven't fully tested everything since I'm mostly waiting for the updated documentation. While this should convert to C# pretty easily, I haven't tested everything out yet. So far, it isn't much of a struggle to transition from Windows' version of Xaml Islands though.

[myth384]

Microsoft.Toolkit.Win32 has a XAML Control WindowsXamlHost to host a UWP Control inside WPF or Winforms projects. It acts as a convenience wrapper around DesktopWindowXamlSource. This feature was removed in Windows Community Toolkit 8, reasoning that Windows App SDK 1.4 introduced XAML Islands... as you may have guessed in the form of DesktopWindowXamlSource...
I created an issue on Github of Windows Community Toolkit to reintroduce the wrappers to work with WinUI 3.