From 15828ebd068219c332334866027a542da5148632 Mon Sep 17 00:00:00 2001 From: ahall Date: Tue, 7 Jul 2026 15:51:36 +0100 Subject: [PATCH] fix: resolve NU1605 blocking TodoApp.Uno restore by bumping Uno.Sdk to 5.6.54 (#506) CommunityToolkit.WinUI.Behaviors 8.2.250402 (pinned in samples/todoapp/TodoApp.Uno/Directory.Packages.props) floors Uno.WinUI at >= 5.5.87, but Uno.Sdk 5.4.5 (the previous global.json pin) resolves Uno.WinUI to 5.4.22, causing a NU1605 package-downgrade restore error on every head (android, ios, maccatalyst, windows, browserwasm, desktop) - not just the desktop head #506 originally reported. Bump Uno.Sdk in samples/todoapp/TodoApp.Uno/global.json from 5.4.5 to 5.6.54 (the latest stable 5.x release), which resolves Uno.WinUI to 5.6.99, clearing the floor. Confirmed via 'dotnet restore' that NU1605 is gone on the desktop, windows, and browserwasm heads (android/ios/ maccatalyst require workloads not available in this environment). This does NOT resolve the original NU1903 finding (Tmds.DBus 0.16.0, GHSA-xrw6-gwf8-vvr9) - Uno.WinUI.Runtime.Skia.X11 keeps floating vulnerable Tmds.DBus 0.16.0 through the entire 5.x line and only switches to the patched Tmds.DBus.Protocol starting at Uno.WinUI 6.0.465, which requires a major-version bump. Filed as a follow-up: #524. Restoring cleanly also surfaced two more pre-existing, unrelated issues that were previously masked by NU1605 (never surfaced because no head ever restored successfully before): - Every Skia-based head (desktop, browserwasm, and almost certainly android/ios/maccatalyst) fails to BUILD with UXAML0001 (EventTriggerBehavior could not be found), because CommunityToolkit.WinUI.Behaviors resolves a dev-prerelease Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI package on those heads instead of the real Microsoft.Xaml.Behaviors.WinUI.Managed package (which the windows head still gets). Filed as a follow-up: #525. - The browserwasm head surfaces two more NU1903 findings for System.Security.Cryptography.Xml 8.0.2. Filed as a follow-up: #526. Given the above, the todoapp-uno CI job (build-samples-todoapp-uno.yml) is intentionally left unwired in build-samples.yml for now - re-enabling it today would turn all-samples-built red on every PR due to #525. Updated the NOTE comments in both workflow files to reflect the new state. Fixes #506 --- .../workflows/build-samples-todoapp-uno.yml | 40 ++++++++++++++----- .github/workflows/build-samples.yml | 25 +++++++----- samples/todoapp/TodoApp.Uno/global.json | 9 ++++- 3 files changed, 51 insertions(+), 23 deletions(-) diff --git a/.github/workflows/build-samples-todoapp-uno.yml b/.github/workflows/build-samples-todoapp-uno.yml index 635a4867..196c4107 100644 --- a/.github/workflows/build-samples-todoapp-uno.yml +++ b/.github/workflows/build-samples-todoapp-uno.yml @@ -1,11 +1,13 @@ name: Build Sample - TodoApp Uno -# NOTE: This workflow is NOT currently wired into build-samples.yml. TodoApp.Uno.csproj fails -# to restore on every head with NU1605 (Uno.WinUI version downgrade caused by -# CommunityToolkit.WinUI.Behaviors' floor vs. the Uno.Sdk pin in global.json) - see the jobs -# below and https://github.com/CommunityToolkit/Datasync/issues/506, which is tracking the fix. -# Re-add the `todoapp-uno` job to build-samples.yml (and to all-samples-built's `needs`) once -# #506 is resolved and TodoApp.Uno.csproj restores cleanly. +# NOTE: This workflow is NOT currently wired into build-samples.yml. #506 fixed the NU1605 +# restore blocker that used to affect every head (see samples/todoapp/TodoApp.Uno/global.json), +# so restore now succeeds everywhere. However, build now fails on every Skia-based head (android, +# ios, maccatalyst, browserwasm, desktop) with UXAML0001/CS1061 (EventTriggerBehavior could not +# be found) - see the `desktop` job below for details and +# https://github.com/CommunityToolkit/Datasync/issues/506 for background. Re-add the +# `todoapp-uno` job to build-samples.yml (and to all-samples-built's `needs`) once that build +# failure is resolved and every head restores AND builds cleanly. on: workflow_call: @@ -139,11 +141,27 @@ jobs: --no-restore desktop: - # NOTE: this head (along with every other head in this file) currently fails to restore - # with NU1605 - see the file-level NOTE above and #506. #506 originally reported the NU1903 - # Tmds.DBus audit warning for this head specifically; that warning alone is harmless (this - # repo does not configure NuGet audit to fail on warnings), but the NU1605 uncovered while - # investigating it turned out to be project-wide, not desktop-specific. + # NOTE: this head (along with every other Skia-based head in this file - android, + # ios-maccatalyst, browserwasm) currently fails to BUILD (not restore) with: + # error UXAML0001: The type {using:Microsoft.Xaml.Interactions.Core}EventTriggerBehavior + # could not be found + # CommunityToolkit.WinUI.Behaviors 8.2.250402 resolves + # Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI 3.0.0-dev.17.g7c09b9114d on Skia heads + # (confirmed via project.assets.json for desktop and browserwasm), which appears to lack the + # Microsoft.Xaml.Interactions.Core types used in Views/TodoListPage.xaml. The `windows` job + # below is unaffected - it resolves the real Microsoft.Xaml.Behaviors.WinUI.Managed 3.0.0 + # package instead. This is a separate, pre-existing bug from the NU1903 Tmds.DBus finding + # below and from the NU1605 restore blocker #506 originally hit (now fixed - see + # samples/todoapp/TodoApp.Uno/global.json) - it was never surfaced before because restore + # always failed first. Tracked as a #506 follow-up issue. + # + # Restore also emits a NU1903 warning for 'Tmds.DBus' 0.16.0 (GHSA-xrw6-gwf8-vvr9 / + # CVE-2026-39959), floated transitively via Uno.WinUI.Runtime.Skia.X11. This is harmless as a + # CI matter today (this repo does not configure NuGet audit to fail on warnings) but is not + # yet resolved - Uno only switches Uno.WinUI.Runtime.Skia.X11 to the patched + # Tmds.DBus.Protocol starting at Uno.WinUI 6.0.465, which requires a major-version bump of + # Uno.Sdk. See https://github.com/CommunityToolkit/Datasync/issues/506 for background and the + # tracked major-version-bump follow-up issue. runs-on: ubuntu-latest steps: - name: Checkout Repository diff --git a/.github/workflows/build-samples.yml b/.github/workflows/build-samples.yml index aa7de6de..3b19ca8c 100644 --- a/.github/workflows/build-samples.yml +++ b/.github/workflows/build-samples.yml @@ -37,17 +37,20 @@ jobs: todoapp-maui: uses: ./.github/workflows/build-samples-todoapp-maui.yml - # NOTE: todoapp-uno (build-samples-todoapp-uno.yml) is intentionally NOT wired in here. - # TodoApp.Uno.csproj fails to restore on every head with: - # NU1605: Detected package downgrade: Uno.WinUI from 5.5.87 to 5.4.22 - # TodoApp.Uno -> CommunityToolkit.WinUI.Behaviors 8.2.250402 -> Uno.WinUI (>= 5.5.87) - # TodoApp.Uno -> Uno.WinUI (>= 5.4.22) - # This is unconditional (CommunityToolkit.WinUI.Behaviors has no TFM condition on its - # PackageReference), so it blocks every TFM, not just the desktop head as originally - # suspected. See https://github.com/CommunityToolkit/Datasync/issues/506, which is tracking - # the underlying Uno.WinUI/CommunityToolkit.WinUI.Behaviors version conflict. Re-enable this - # job (add it back to the jobs list and to all-samples-built's needs below) once #506 is - # resolved and TodoApp.Uno.csproj restores cleanly. + # NOTE: todoapp-uno (build-samples-todoapp-uno.yml) is intentionally NOT wired in here yet. + # #506 fixed the NU1605 restore blocker that used to affect every head (bumped Uno.Sdk in + # samples/todoapp/TodoApp.Uno/global.json from 5.4.5 to 5.6.54), so TodoApp.Uno.csproj now + # restores cleanly. However, restoring cleanly surfaced a separate, pre-existing bug: on every + # Skia-based head (android, ios, maccatalyst, browserwasm, desktop - confirmed for desktop and + # browserwasm; android/ios/maccatalyst require workloads not available where this was + # verified), CommunityToolkit.WinUI.Behaviors 8.2.250402 resolves + # Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI 3.0.0-dev.17.g7c09b9114d instead of the real + # Microsoft.Xaml.Behaviors.WinUI.Managed package (which the windows head still gets), and that + # substitute is missing the Microsoft.Xaml.Interactions.Core types used in + # Views/TodoListPage.xaml, so build fails with UXAML0001/CS1061 (EventTriggerBehavior could not + # be found). This was never surfaced before because restore always failed first. See the + # tracking issue for this build failure (filed as a #506 follow-up) - re-add this job once + # that's resolved and every head restores AND builds cleanly. # Single aggregation point so branch protection only needs to require one check, # regardless of how many sample workflows are added over time. diff --git a/samples/todoapp/TodoApp.Uno/global.json b/samples/todoapp/TodoApp.Uno/global.json index 694b05a7..7cef2161 100644 --- a/samples/todoapp/TodoApp.Uno/global.json +++ b/samples/todoapp/TodoApp.Uno/global.json @@ -1,7 +1,14 @@ { // To update the version of Uno please update the version of the Uno.Sdk here. See https://aka.platform.uno/upgrade-uno-packages for more information. + // Bumped from 5.4.5 (-> Uno.WinUI 5.4.22) to 5.6.54 (-> Uno.WinUI 5.6.99) to resolve NU1605: + // CommunityToolkit.WinUI.Behaviors 8.2.250402 floors Uno.WinUI at >= 5.5.87, which is higher + // than what Uno.Sdk 5.4.5 resolves, causing a package-downgrade restore error on every head. + // This does NOT resolve the separate NU1903 (Tmds.DBus 0.16.0) advisory on the desktop head - + // Uno.WinUI.Runtime.Skia.X11 keeps floating vulnerable Tmds.DBus 0.16.0 through the entire + // 5.x line and only switches to the patched Tmds.DBus.Protocol starting at Uno.WinUI 6.0.465. + // See https://github.com/CommunityToolkit/Datasync/issues/506. "msbuild-sdks": { - "Uno.Sdk": "5.4.5" + "Uno.Sdk": "5.6.54" }, "sdk":{ "allowPrerelease": false