fix: resolve TodoApp.Uno Skia build failures and bump Uno Platform 5 -> 6#533
Merged
Merged
Conversation
…-> 6
Removes the dead EventTriggerBehavior/InvokeCommandAction Interaction.Behaviors
block in Views/TodoListPage.xaml that caused UXAML0001 (Microsoft.Xaml.Interactions.Core
could not be found) on every Skia-based head (android, ios, maccatalyst,
browserwasm, desktop). The Uno port of XAML Behaviors (unoplatform/Uno.XamlBehaviors)
only ships Microsoft.Xaml.Interactivity, never a Microsoft.Xaml.Interactions.Core
equivalent, in any version - confirmed via NuGet, so pinning a different package
version could never fix this. The behavior was already dead code per its own
comment ("the event is not triggered. Handling in code behind for now") -
TodoListPage.xaml.cs's DataContextChangedHandler already invokes
ViewModel.LoadPageCommand directly. (CommunityToolkit#525)
Also bumps Uno.Sdk from 5.6.54 to 6.5.36 (-> Uno.WinUI 6.5.237) (CommunityToolkit#524), which:
- Resolves the outstanding NU1903 Tmds.DBus 0.16.0 advisory on the desktop head
for free (Uno.WinUI.Runtime.Skia.X11 switches to patched Tmds.DBus.Protocol
starting at 6.0.465).
- Lifts the Uno.Wasm.Bootstrap net9.0+ TargetFramework guard that was blocking
the browserwasm head once the EventTriggerBehavior fix above let restore/build
get far enough to hit it (Uno.Sdk 6.x resolves Uno.Wasm.Bootstrap 10.0.96
instead of the 5.x line's 8.0.23).
Required manual migration per https://platform.uno/docs/articles/migrating-to-uno-6.html:
- Platforms/Desktop/Program.cs: Uno.UI.Runtime.Skia -> Uno.UI.Hosting,
SkiaHostBuilder -> UnoPlatformHostBuilder, UseWindows() -> UseWin32().
- Platforms/Android/Main.Android.cs: removed the UniversalImageLoader
configuration, which Uno 6 now handles internally via Skia rendering.
Re-enables the todoapp-uno CI job in build-samples.yml (all 5 heads: android,
ios-maccatalyst, windows, browserwasm, desktop), removing the stale
disabled-pending-fix comments in both workflow files.
Verified locally:
- desktop: restore + build clean (no workload required).
- browserwasm: restore + build clean, after installing the wasm-tools workload
into a separate user-writable .NET SDK (system-wide /usr/local/share/dotnet
is root-owned in this environment).
- Root Datasync.Toolkit.sln (main library, unaffected by this change) still
restores and builds clean.
Not verified locally (relying on CI, same limitation the issue reporter noted):
- android: workload installs, but the Android SDK (platform-tools/build-tools)
isn't provisioned in this environment, so the build fails before reaching any
application code.
- ios / maccatalyst: require a full Xcode install (only Command Line Tools are
available here).
- windows: requires a Windows runner.
This was referenced Jul 10, 2026
TodoApp.Uno: trim analysis warnings (IL2026/IL2104/IL2121) on browserwasm/ios/maccatalyst heads
#534
Closed
Closed
This was referenced Jul 10, 2026
adrianhall
added a commit
that referenced
this pull request
Jul 10, 2026
…Uno browserwasm/ios/maccatalyst (#548) Now that #533 fixes the TodoApp.Uno build failure, these three heads build successfully in CI for the first time and surface IL trim-analyzer warnings that were previously masked. dotnet build enables the trim analyzer on these SDKs by default, but this CI pipeline only ever runs 'dotnet build', never 'dotnet publish -p:PublishTrimmed=true', so the warnings are diagnostic noise on framework APIs (EF Core's DbContext ctor, JsonSerializer.Serialize, Uno's own Hosting/Navigation surface and source-generated BindableMetadata.g.cs), not sample bugs. Same fix pattern as #531 (TodoApp.Avalonia/TodoApp.MAUI): add SuppressTrimAnalysisWarnings, scoped via GetTargetPlatformIdentifier to match TodoApp.MAUI.csproj's existing convention. android/desktop/windows did not surface these warnings in the CI run linked from the issue, so they are intentionally left unsuppressed. Verified locally: - net10.0-desktop: restore + build clean (no workload required). - net10.0-browserwasm: restore + build clean after installing the wasm-tools workload into a separate user-writable .NET SDK (system-wide SDK is root-owned in this environment). Confirmed via negative control (reverting the change) that IL2026/IL2104/IL2121 appear 18 times without the fix and 0 times with it, on an otherwise identical build. - Root Datasync.Toolkit.sln (unaffected by this change) still restores and builds clean; Client.Test passes 1432/1432. Live server DB tests fail in this sandbox due to no Docker daemon (pre-existing environment limitation, unrelated to this change). Not verified locally (relying on CI, same limitation noted in #531/#533): - ios / maccatalyst: require a full Xcode install (only Command Line Tools available here). - android: requires the Android SDK/workload. - windows: requires a Windows runner. Fixes #534 Co-authored-by: ahall <ahall@cloudflare.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the
TodoApp.Unosample's build failures on Skia-based heads (android, ios, maccatalyst, browserwasm, desktop), and bumpsUno.Sdk5 -> 6, which resolves two outstandingNU1903advisories along the way.Closes #525
Closes #524
Closes #526
What's in here
#525 -
EventTriggerBehavior/UXAML0001Views/TodoListPage.xamlused anEventTriggerBehavior/InvokeCommandActionpair (fromMicrosoft.Xaml.Interactions.Core) to fireLoadPageCommandonLoaded. This behavior was already dead code - its own comment says "the event is not triggered. Handling in code behind for now", andTodoListPage.xaml.cs'sDataContextChangedHandleralready callsViewModel.LoadPageCommand.ExecuteAsync(null)directly.On every non-Windows (Skia) head,
CommunityToolkit.WinUI.BehaviorsresolvesUno.Microsoft.Xaml.Behaviors.Interactivity.WinUIinstead of the realMicrosoft.Xaml.Behaviors.WinUI.Managed. I confirmed via NuGet (across every released version, prerelease and stable, including the latest8.2.251219CommunityToolkit.WinUI.Behaviors) that the Uno port (unoplatform/Uno.XamlBehaviors) only ever shipsMicrosoft.Xaml.Interactivity(the base attached-property infrastructure) - it has never shipped aMicrosoft.Xaml.Interactions(Core triggers/actions) equivalent. So option 1 from the issue (pin a different version) was a dead end; the fix is to remove the dead behavior block and its now-unusedxmlns:interactionsnamespace.#524 - Uno Platform 5 -> 6
Bumped
Uno.Sdkinglobal.jsonfrom5.6.54to6.5.36(->Uno.WinUI 6.5.237). This was necessary, not optional: once the #525 fix let thebrowserwasmhead's build get past the XAML compile stage, it hit a new (previously-masked) failure -Uno.Wasm.Bootstrap 8.0.23(floored by Uno.WinUI 5.x) hard-rejects any project targetingTargetFrameworkVersion >= 9.0. Uno.Sdk 6.x resolvesUno.Wasm.Bootstrap 10.0.96instead, which lifts that guard.Required manual migration per the Uno 6 migration guide:
Platforms/Desktop/Program.cs:Uno.UI.Runtime.Skia->Uno.UI.Hosting,SkiaHostBuilder->UnoPlatformHostBuilder,.UseWindows()->.UseWin32().Platforms/Android/Main.Android.cs: removed theUniversalImageLoaderconfiguration - Uno 6 now handles image loading internally via Skia rendering.#526 -
System.Security.Cryptography.XmlNU1903 (browserwasm)Resolved as a side effect of the #524 bump:
System.Security.Cryptography.Xmlnow resolves to10.0.7(up from the vulnerable8.0.2) on thebrowserwasmhead, confirmed via a cleandotnet restorewith noNU1903warnings.As a bonus, the bump also resolves the original
Tmds.DBusNU1903finding from #506 on thedesktophead (Uno.WinUI.Runtime.Skia.X11switches to the patchedTmds.DBus.Protocolstarting atUno.WinUI 6.0.465).CI
Re-enabled the
todoapp-unojob (all 5 heads) inbuild-samples.yml, and removed the stale "disabled pending fix" comments in both workflow files.Verification
Verified locally:
desktop:dotnet restore+dotnet buildclean, no workload required.browserwasm:dotnet restore+dotnet buildclean, after installing thewasm-toolsworkload (into a separate user-writable .NET SDK, since the system-wide SDK install wasn't writable in my environment). NoNU1903warnings on restore (confirms Investigate resolving NU1903 for System.Security.Cryptography.Xml in Uno browserwasm sample head #526).Datasync.Toolkit.sln(main library, unaffected by this change) still restores and builds clean.Not verified locally (relying on CI for these, same limitation noted by the original issue reports):
android: theandroidworkload installs, but the Android SDK (platform-tools/build-tools) wasn't provisioned in my environment, so the build fails before reaching any application code.ios/maccatalyst: require a full Xcode install (only Command Line Tools available in my environment).windows: requires a Windows runner.