x:bind failing to resolve some objects

[dotMorten]

Describe the bug

I'm adding AoT support to our controls library and hitting some odd behaviors for some properties when moving to x:Bind: They seem to resolve certain properties to null or not resolve at all, but if I modify the binding and undo it while hot-reload is running, it snaps out of it and starts rendering. The properties are coming from immutable objects that aren't changing, so it's not because they were null to begin with.

ReproSteps.mp4

Steps to reproduce the bug

1. Unzip and run the following sample: toolkitrepro.zip
2. Follow the steps shown in the above video.

Another weird behavior I've noticed: In FeatureForm.Theme.xaml if I modify the template for FieldFormElementView and change

<TextBlock Text="{x:Bind Element.Label}" Style="{StaticResource FeatureFormViewTitleStyle}"/>

to

<ContentControl Content="{x:Bind Element}">
    <ContentControl.ContentTemplate>
        <DataTemplate x:DataType="forms:FormElement">
            <TextBlock Text="{x:Bind Label}" Style="{StaticResource FeatureFormViewTitleStyle}"/>
        </DataTemplate>
    </ContentControl.ContentTemplate>
</ContentControl>

the label does resolve and render.

Also if I run the FeatureFormView sample and set a break-point in the SelectTemplateCore method src\Toolkit\Toolkit\UI\Controls\FeatureForm\FieldTemplateSelector.cs, I notice that the item parameter is null, until I do the above trick of modifying and undoing the change to the x:bind expression and hot-reload somehow makes the item property now evaluate to something.

Expected behavior

x:Bind works as old-style Bindings with would have, or as they do when hot-reload updated bindings kick in.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.7.1: 1.7.250401001

Windows version

Windows 11 (24H2): Build 26100, Windows 11 (23H2): Build 22631

Additional context

No response

[AndrewKeepCoding]

Manually setting the ItemsSource works and populates the FlipView, so the data is right there. Some related code is not being generated maybe?

private void FlipView_Loaded(object sender, RoutedEventArgs e)
{
    if (sender is not FlipView flipView ||
        flipView.ItemsSource is not null ||
        flipView.DataContext is not MediaPopupElement mediaPopupElement)
    {
        return;
    }

    flipView.ItemsSource = mediaPopupElement.Media;
}

[dotMorten]

@AndrewKeepCoding That's a really nice find! That at least gives an (ugly) workaround for one of the issues and a little bit to go on, but still a lot of issue with the other properties in the Forms sample.

Update: When digging in deeper it really isn't a workaround, as the issue still persists in multiple ways. There's definitely something odd going on. I can also repro with UWP.
This is a definite blocker for us being able to fully support AoT.

[dotMorten]

Here's a MUCH simpler reproducer:
ChatApp.zip

Run the app and see a bunch of empty little gray and blue bubbles:

Next (while app is running) open Themes\generic.xaml and in line 63, edit binding expression for the Text property by deleting the starting {` character, and immediately undo that change. Notice that the text in the bubbles are now showing.

I've now hit this issue in multiple ways over the last few months and is a real showstopper for achieving full AoT support, since I can't switch to x:Bind.

[Skittles2519]

For your chat app, the binding for your text is set in a resource control. When they are set here you need to do some additional steps. I also don't think you can do them in a Window and will need to be set in a Page. The page will need to reference your resource dictionary in its resources. Here is your chat app with one way x:Bind in the messages on first run.

ChatApp2.zip

https://learn.microsoft.com/en-us/windows/uwp/data-binding/data-binding-in-depth#resource-dictionaries-with-xbind

[Hemantxk]

Hello @Skittles2519 thanks for sharing a solution & guidance on x:Bind.

@dotMorten I was able to reproduce this issue in your sample ChatApp. To solve it, I have added local:ThemeResources/ in MergedDictionaries of App.xaml and re-run the app. With that, issue was no longer reproducible for me, here is updated App.xaml:

<?xml version="1.0" encoding="utf-8"?>
<Application
    x:Class="ChatApp.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:ChatApp">
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" />
                <!-- Other merged dictionaries here -->
                <local:ThemeResources/>     <== new entry
            </ResourceDictionary.MergedDictionaries>
            <!-- Other app resources here -->
        </ResourceDictionary>
    </Application.Resources>
</Application>

Let me know if it resolves your issue or not.

[dotMorten]

@Hemantxk Interesting workaround. Unfortunately that won't really work for 3rd party custom control libraries. The Themes\Generic.xaml file has always been implicitly included and this requirement would be a breaking change, even for those not requiring AoT.
It's also weird that this change is required for some of the x:bind features, but not others.

[Hemantxk]

@dotMorten I think you can try adding external library's ResourceDictionary in the App.xaml when you are using that particular library in your app. Please share a repro if it doesn't work for you.
I don't think there is any breaking change here (from framework perspective) as I am able to reproduce issue even with WindowsAppSDK 1.4 & 1.5 (pre-AOT) and guidance in documentation has been present for a long time.

[dotMorten]

@Hemantxk Here's the issue: Historically, when building custom control libraries, you never had to explicitly include the themes\generic.xaml resources. It automatically includes and applies those styles. So a library that is already shipping is relying on this behavior. If that library then wants to improve and start supporting AoT, that library now need to rely on code generation for the default styles. If a user then upgrades to this new version, even if they don't want/need AoT support in their app, their application now breaks and will have to somehow need to magically know that they need to go into their app.xaml file and add this entry for it to work again. This sets a poor experience with the developer and sets us up for bug reports and support requests - especially because the experience is either a crash that isn't meaningful/helpful, or parts of the controls just stops rendering like is the case in the second reproducer

I could see the argument that to get AoT support in your app this would be a required step to do, but for those who don't, or are not ready to adopt AoT, they won't be able to skip this step, because the change required to support AoT in the library forces everyone using that library to make this change.
That requirement makes it a no-go for us to add AoT support at this point.

guidance in documentation has been present for a long time

What guidance? Could you point me to this?

[zinniaa]

@dotMorten Thanks for the detailed explanation. Just to understand better, could you share a scenario where x:Bind works without explicitly including themes\generic.xaml?

Also, I’m not sure how this issue is directly related to AOT. From what I’ve tested, the issue you’re describing also reproduces in your sample app when using WinAppSDK 1.5, which predates official AOT support. That suggests this behaviour isn’t newly introduced by AOT, but rather something that’s been around.

As for the documentation on using x:Bind with resource dictionary, you can find it here: https://learn.microsoft.com/en-us/windows/uwp/data-binding/data-binding-in-depth#resource-dictionaries-with-xbind

[dotMorten]

Here's an updated sample that adds a title to the ChatView control.
ChatApp2.zip

You can see that the title is using x:bind as well and works just fine:

However the text bubbles doesn't show unless I switch to {Binding}, or use your proposed workaround.

Also, I’m not sure how this issue is directly related to AOT

For supporting AoT in item templates, we need to use x:Bind. So you're right it isn't directly AoT related, but it is required for us to be AoT compatibly in the custom control libraries.