TodoApp.MAUI: MainPage.xaml binding not compiled due to explicit Source (XamlC XC0025)

[adrianhall]

Summary

Discovered while adding Windows CI coverage for TodoApp.MAUI in #510 (PR #514, build-samples-todoapp-windows.yml). Building the sample produces a XAML compiler (XamlC) warning:

MainPage.xaml(58,25): XamlC warning XC0025: Binding was not compiled because it has an explicitly set Source property and compilation of bindings with Source is not enabled. Consider enabling this optimization by setting the <MauiEnableXamlCBindingWithSourceCompilation>true</MauiEnableXamlCBindingWithSourceCompilation> in your project file and make sure the correct x:DataType is specified for this binding. See https://learn.microsoft.com/dotnet/maui/fundamentals/data-binding/compiled-bindings for more information.

Root cause

samples/todoapp/TodoApp.MAUI/MainPage.xaml:58:

<Entry
    x:Name="addItemEntry"
    ...
    ReturnCommandParameter="{Binding Text, Source={x:Reference addItemEntry}}"
    ... />

MainPage.xaml has x:DataType="viewmodels:MainViewModel" set at the ContentPage level (enabling compiled bindings generally), but the ReturnCommandParameter binding on the addItemEntry Entry explicitly overrides Source to reference the entry itself ({x:Reference addItemEntry}) rather than the page's BindingContext. XamlC does not compile bindings that use an explicit Source unless MauiEnableXamlCBindingWithSourceCompilation is opted into project-wide, because it also needs a correct x:DataType scoped to that Source's type for the compiler to generate typed accessor code.

This is a performance-only warning (falls back to slower reflection-based binding for this one binding) — it does not affect correctness or produce incorrect behavior.

Additional information needed / design decisions

Two independent remediation paths, need a decision on which to take (or both):

1. Project-wide opt-in: set <MauiEnableXamlCBindingWithSourceCompilation>true</MauiEnableXamlCBindingWithSourceCompilation> in TodoApp.MAUI.csproj. Simplest fix, but this is an opt-in feature per Microsoft's docs specifically because it can surface other, currently-hidden compiled-binding diagnostics across the rest of the project once enabled — the change should be verified with a full rebuild to confirm no new warnings/errors appear elsewhere in the project (there's only one other data-bound view in this project, MainPage.xaml's item template, which already sets x:DataType="models:TodoItem" correctly).
2. Restructure the binding to avoid needing an explicit Source: since Source={x:Reference addItemEntry} is only used to pass the Entry's own Text as the command parameter, consider binding Text via a two-way binding to a view-model property instead, and removing the need for ReturnCommandParameter + x:Reference entirely (letting AddItemCommand read the already-bound view-model text property). This is a more invasive change to the view-model contract, so it's the higher-effort option.

Suggested fix

Start with option 1 above (project-wide MauiEnableXamlCBindingWithSourceCompilation) as the minimal, low-risk fix, since this project only has one Source-based binding today. Also add the correct x:DataType for the Entry's own type (x:DataType="Entry" scoped appropriately, e.g. via a nested DataTemplate/binding scope, or accept that XamlC compiles it against the reference's own type) so the compiler can actually generate typed code once the flag is enabled — verify by rebuilding and confirming the XC0025 warning is gone with no new warnings introduced.

Related

• Add CI workflow to build Windows-only /samples heads (Phase 2 of #509) #510 / PR ci: add build-samples workflow for Phase 2 Windows-only heads (#510) #514 — Phase 2 Windows CI for /samples, where this warning was first surfaced (no CI previously built this project at all).