Summary
Discovered while fixing #506's NU1605 restore blocker. Once TodoApp.Uno.csproj restores cleanly (Uno.Sdk bumped 5.4.5 -> 5.6.54), building any Skia-based head fails:
error UXAML0001: The type {using:Microsoft.Xaml.Interactions.Core}EventTriggerBehavior could not be found
error UXAML0001: Processing failed for file .../Views/TodoListPage.xaml
followed by cascading CS1061/CS0103 errors (InitializeComponent, Bindings, NotificationQueue, Splash not found) once the XAML compiler bails out.
This was never surfaced before because restore always failed first (see #506) - this is a separate, pre-existing bug independent of the NU1605/NU1903 package-version issues.
Root cause (confirmed via project.assets.json)
CommunityToolkit.WinUI.Behaviors 8.2.250402 (pinned in samples/todoapp/TodoApp.Uno/Directory.Packages.props) depends on Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI on non-Windows heads. On every head I could test (net10.0-desktop, net10.0-browserwasm), it resolves to:
Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI/3.0.0-dev.17.g7c09b9114d
a dev-prerelease build, which appears to be missing the Microsoft.Xaml.Interactions.Core namespace (EventTriggerBehavior, etc.) used in Views/TodoListPage.xaml.
By contrast, on net10.0-windows10.0.26100 the same CommunityToolkit.WinUI.Behaviors package resolves the real package instead:
Microsoft.Xaml.Behaviors.WinUI.Managed/3.0.0
which does include Microsoft.Xaml.Interactions.Core. I was not able to test android/ios/maccatalyst locally (missing workloads), but since they share the same Skia-based rendering path as desktop/browserwasm, they almost certainly hit the same failure.
Impact
Blocks re-enabling the todoapp-uno job in build-samples.yml (see #506) for every head except possibly windows.
Ask
Investigate one of:
- Find/pin a non-prerelease version of
Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI (or whatever CommunityToolkit.WinUI.Behaviors version pulls one) that includes Microsoft.Xaml.Interactions.Core.
- Replace the
interactions:EventTriggerBehavior usage in Views/TodoListPage.xaml with an Uno-native / cross-platform-safe alternative.
- Confirm whether this is a known upstream Uno Platform / CommunityToolkit.WinUI.Behaviors issue with an existing fix or tracking issue.
Related
Summary
Discovered while fixing #506's NU1605 restore blocker. Once
TodoApp.Uno.csprojrestores cleanly (Uno.Sdk bumped 5.4.5 -> 5.6.54), building any Skia-based head fails:followed by cascading
CS1061/CS0103errors (InitializeComponent,Bindings,NotificationQueue,Splashnot found) once the XAML compiler bails out.This was never surfaced before because restore always failed first (see #506) - this is a separate, pre-existing bug independent of the NU1605/NU1903 package-version issues.
Root cause (confirmed via
project.assets.json)CommunityToolkit.WinUI.Behaviors 8.2.250402(pinned insamples/todoapp/TodoApp.Uno/Directory.Packages.props) depends onUno.Microsoft.Xaml.Behaviors.Interactivity.WinUIon non-Windows heads. On every head I could test (net10.0-desktop,net10.0-browserwasm), it resolves to:a dev-prerelease build, which appears to be missing the
Microsoft.Xaml.Interactions.Corenamespace (EventTriggerBehavior, etc.) used inViews/TodoListPage.xaml.By contrast, on
net10.0-windows10.0.26100the sameCommunityToolkit.WinUI.Behaviorspackage resolves the real package instead:which does include
Microsoft.Xaml.Interactions.Core. I was not able to testandroid/ios/maccatalystlocally (missing workloads), but since they share the same Skia-based rendering path as desktop/browserwasm, they almost certainly hit the same failure.Impact
Blocks re-enabling the
todoapp-unojob inbuild-samples.yml(see #506) for every head except possiblywindows.Ask
Investigate one of:
Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI(or whatever CommunityToolkit.WinUI.Behaviors version pulls one) that includesMicrosoft.Xaml.Interactions.Core.interactions:EventTriggerBehaviorusage inViews/TodoListPage.xamlwith an Uno-native / cross-platform-safe alternative.Related