[turbobobbytraykov]

.NET 9 support ended on 2026-11-10; 9.0.23 was its last patch. This PR moves the samples browser, the 331 standalone samples, the sample template and the two CI helper tools to .NET 10, the current LTS (supported until 2028-11-14). Uno.Sdk stays at 6.7.45 and the Infragistics packages at 26.1.1000-alpha.25.

Before the showcase: what to decide

• Merge and deploy Set explicit Cache-Control headers for the WebAssembly site #16 (cache headers) first.
  • On .NET 10, uno-config.js names a fingerprinted dotnet.<hash>.js, and the bootstrapper writes uno-config.js after it has named the package folder. A later deploy that keeps the folder name but changes dotnet.<hash>.js would leave a browser that kept the old uno-config.js asking for a deleted file, and the app would not start. That's the scenario of Uno.Wasm.Bootstrap issues #1076 and #1090; I haven't reproduced it here.
  • The switch to .NET 10 itself is safe: its package folder has a new name, and index.html is already no-cache.
  • Staging sends uno-config.js without Cache-Control today, so browsers may keep it for a while on their own. Set explicit Cache-Control headers for the WebAssembly site #16 makes it no-cache; copies cached before Set explicit Cache-Control headers for the WebAssembly site #16 is deployed expire on the browser's own schedule, so deploy Set explicit Cache-Control headers for the WebAssembly site #16 some time before the event.
  • Set explicit Cache-Control headers for the WebAssembly site #16's web.config comment lists _framework/dotnet.js and blazor.boot.json as no-cache files. On .NET 10 they're gone, and dotnet.<hash>.js correctly gets the one-year policy. Whichever of Set explicit Cache-Control headers for the WebAssembly site #16 and this PR merges second should update that comment; I'll do it.
• Suggested order: Add a pull request build for the site and every platform #20 (PR build), Set explicit Cache-Control headers for the WebAssembly site #16, Keep the gzip copy of dotnet.native.wasm #19, Show the home page first and warm the controls afterwards #17, then this PR. I'll update the remaining PRs after each merge.
  • Keep the gzip copy of dotnet.native.wasm #19 edits the same DropGzipCopies target as this PR, so whichever merges second gets a one-line conflict.
  • Once Add a pull request build for the site and every platform #20 is in vnext, updating this branch runs its platform matrix on .NET 10.
• Turn off the PWA service worker #12, Preload only the six Open Sans faces the samples use #13 and Ship only Brotli copies of the WebAssembly site #14 are already merged. This branch is merged with vnext and moves their publish targets (retiring service worker, Open Sans subset, gzip removal) from net9.0-browserwasm to net10.0-browserwasm; otherwise .NET 10 would skip them.
• The PWA is off since Turn off the PWA service worker #12. The .NET 10 bootstrapper's service worker deletes every Cache Storage cache on the origin except its own when it activates, and staging.infragistics.com and www.infragistics.com serve other apps too. With the PWA off, the app registers no worker, and service-worker.js is the retiring worker from Turn off the PWA service worker #12.
• Risk for the WebAssembly app at the event: low, by the local tests below.
  • All 331 samples behave the same as on .NET 9.
  • Startup showed no measurable difference.
  • Samples load faster.
  • The Brotli download is 0.2 MB larger.
  • Not covered: nginx, CloudFront and a staging deploy of the .NET 10 build. Please deploy to staging and check it before the event.
• Mobile platforms on .NET 10: Android and iOS build, checked with Add a pull request build for the site and every platform #20's matrix (see "Platforms on .NET 10"). Mac Catalyst can't build on .NET 9 or .NET 10, for a reason outside this repository (see Add a pull request build for the site and every platform #20).
• Rollback: git revert -m 1 <merge commit> on vnext, then push. CI rebuilds .NET 9 and deploys it to staging. If Keep the gzip copy of dotnet.native.wasm #19 merged after this PR, the revert conflicts on DropGzipCopies. Browsers keep the .NET 10 fingerprinted files in their caches, which is harmless.
• Team setup:
  • Developers need the .NET 10 SDK, 10.0.1xx band; uno-check installs it.
  • Visual Studio 2026 is the supported IDE.
  • Visual Studio 2022 17.14 also builds the projects with the pinned SDK band: I checked the browser's desktop head with its MSBuild. But Microsoft supports .NET 10 targets only in Visual Studio 2026.

Changes

• global.json: SDK 9.0.315 → 10.0.100, still with rollForward: latestPatch, so it uses the newest 10.0.1xx installed.
  • CI gets the newest 10.0.1xx too, 10.0.115 today: actions/setup-dotnet applies latestPatch. vnext's 9.0.315 pin built with 9.0.321, as the Emscripten cache key shows.
  • The 1xx band is the one Visual Studio 2022 17.14 can load: its SDKs require MSBuild 17.14, while 10.0.2xx and later require MSBuild 18 (Visual Studio 2026).
  • Commits 255506c and 8776d27 pinned .NET 9 because Visual Studio 2022 couldn't load the projects once the .NET 10 SDK was installed (it picked a newer band). Pinning the 1xx band avoids that.
• Target frameworks: net9.0-* → net10.0-* in SamplesBrowser.csproj, all 331 samples/**/Sample.csproj, and scripts/uno-template/Sample.csproj (so newly scaffolded samples match). The $(InfragisticsUnoBuild)\net9.0\ HintPaths stay: that folder is the libraries' own build output, and net10.0 apps use the net9.0 libraries as they are.
• tests/SampleLinks and scripts/source-viewer: net9.0 → net10.0. CI runs them with dotnet run, and with only the .NET 10 runtime installed a net9.0 tool would not start.
• Workflow: --framework and TargetFrameworks → net10.0-browserwasm. The publish flags, the Emscripten cache (WasmCachePath still works) and the Validate deployable site checks pass as they are.
• Publish targets: PublishDocumentationSource, and the targets from Turn off the PWA service worker #12, Preload only the six Open Sans faces the samples use #13 and Ship only Brotli copies of the WebAssembly site #14 (PublishRetiringServiceWorker, PublishOpenSansSubset, DropGzipCopies), now run for net10.0-browserwasm. Their comments name the .NET 10 bootstrapper and SDK too: both still write service-worker.js and .gz copies.
• SampleHostPage.xaml.cs: WebView2 → Microsoft.UI.Xaml.Controls.WebView2. On net10.0-desktop, Uno 6.7 adds the WebView2Aot package, and the unqualified name then resolves to a namespace (CS0118), so the desktop head didn't compile.
• README: IDE and SDK requirements, and the publish example.

What the WebAssembly build changes

I did a local AOT publish of this branch, after merging vnext 7c3993e, with the CI flags, and compared it with CI's .NET 9 build of the same commit.

• Bootstrapper: Uno.Sdk 6.7.45 picks Uno.Wasm.Bootstrap 10.0.98 for net10.0 instead of 9.0.23. Uno.WinUI 6.7.359, SkiaSharp 3.119.4 and HarfBuzzSharp 8.3.1.1 are unchanged.
• Files: blazor.boot.json and the unfingerprinted dotnet.js are gone. dotnet.<hash>.js replaces them, and uno-config.js names it. 1,383 → 1,378 files.
• Size:
  • dotnet.native.wasm is 112.3 → 116.3 MB raw, but only 18.40 → 18.54 MB as Brotli.
  • All Brotli copies together: 33.39 → 33.58 MB.
• Warnings: none new. The six IL2026 trim warnings are gone; the IL2075 and IL2104 ones are unchanged.

Tested locally

Sites were served by IIS Express with the site's own web.config and loaded in headless Chrome. nginx and CloudFront weren't involved.

After merging vnext (with #9 and #11–#14):

• An AOT rebuild passes Validate deployable site, including the checks from Turn off the PWA service worker #12, Preload only the six Open Sans faces the samples use #13 and Ship only Brotli copies of the WebAssembly site #14: the PWA is off, the font manifest lists 6 faces, and no .gz is published.
• One pass over all 331 samples (one run, no .NET 9 counterpart): the same 328 render and the same 3 fail. There were no console errors, and the median load was 611 ms.

Before that merge (A/B against .NET 9, two runs per build):

• All 331 samples, opened as direct links (the documentation iframe view), with screenshots compared pixel by pixel:

  • The same 328 render on both, and the same 3 fail on both:
    • grids/data-grid/binding-remote-data (Remote-data grid sample freezes the browser tab on WebAssembly #10) hangs after loading.
    • charts/data-chart/data-annotation-multiple-with-stocks hangs.
    • maps/geo-map/display-esri-imagery doesn't load.
  • No new console errors.
  • Median load time per sample: 906–931 ms → 658–664 ms. None is twice as slow.
  • All 12 screenshot differences are timing or live data:
    • In 9 samples, .NET 9 still showed Uno's splash, or its progress bar, 2.5 s after the sample loaded.
    • binding-live-data and pie-chart/animation show live or animated data. I compared the two binding-live-data screenshots by eye: both render the full grid.
    • charts/toolbar/custom-tool logs the same CORS error on both builds. It fetches an icon from svgrepo.com, which is blocked whichever build serves it.

• Startup of the full app (home page, 2 sessions × 4 loads per build; the PWA was still on then):

  • first load: 7.70 → 8.02 s
  • repeat load: 6.91 → 6.62 s

  Both differences are within run-to-run variation.

• Desktop head: all 331 samples, Release builds on Windows, through the repository's own smoke runner (SAMPLES_SMOKE in SmokeRunner.cs), including its property-editor interactions. .NET 9 (vnext 7c3993e) and .NET 10 behave the same:

  • .NET 9: 330 OK; .NET 10: 329 OK. No failures and no unhandled exceptions on either.
  • The same two blank renders: the Bing and Esri imagery maps, which depend on external tile services.
  • The same 191 property-editor interactions, with the same outcomes.
  • Both froze on charts/data-chart/data-annotation-multiple-with-stocks, which also hangs in the browser on both versions. That's a data chart issue unrelated to .NET 10.
  • On .NET 10, grids/data-grid/row-pinning once made no progress for 3 minutes during the full run. Run on its own, it passed 2 of 2 times on each version, in about 4 s.

• Other builds:

  • net10.0-desktop builds with the .NET 10 CLI and with Visual Studio 2022 17.14's MSBuild.
  • Three standalone samples (category chart, data grid, geo map) build for net10.0-browserwasm and net10.0-desktop.
  • CI helpers: SampleLinks and the source-viewer self-test pass.

Platforms on .NET 10

Temporary draft #22 (this PR combined with an earlier version of #20, since closed) ran that PR build on .NET 10:

• Passed: the WebAssembly site build, the samples browser for android and desktop, and three samples for android, desktop, browserwasm and ios. iOS used Xcode 26.0.1 and the Platforms/iOS files that Add a pull request build for the site and every platform #20 adds.
• Mac Catalyst fails, as it does on .NET 9: Uno.WinUI.Runtime.Skia.AppleUIKit brings Uno.icu-ios, which has no Mac Catalyst library, so the link fails. Add a pull request build for the site and every platform #20 explains it and leaves Mac Catalyst out of the matrix.

Not tested

• iOS and Android at run time: the platforms above were built, not run on devices or emulators.
• nginx, CloudFront and staging with the .NET 10 build.

Not in this PR

• Uno 7: Uno.WinUI 7.0 is stable, but Uno 7 drops net9 assets and says 6.x-built libraries are binary-incompatible. The Infragistics packages are built with Uno 6.5.
• .NET 11: Uno 6 supports up to .NET 10.

🤖 Generated with Claude Code

[gmurray81]

I merged vnext into this branch (821592d) so it merges cleanly again, and took the SDK pin out. Since #23, vnext's global.json names only the Uno.Sdk, and this branch now matches it: nothing pins the .NET SDK, locally or in CI.

• global.json: vnext's version, with no sdk section, instead of 10.0.100 + latestPatch. Builds use the newest SDK installed.
• Workflows: build-and-deploy.yml and pr-build.yml install the newest .NET 10 SDK (setup-dotnet with dotnet-version: 10.0.x) instead of reading global.json. The deploy step from Don't pin the .NET SDK #23 that wrote a 9.0.315 pin into global.json for CI runs is gone.
• Visual Studio 2022 17.14: with nothing pinned, it uses the newest SDK it can load. On a machine with 9.0.313 and 10.0.401, its MSBuild resolved 9.0.313. So it builds the net10.0 targets once a 10.0.1xx SDK is installed. The README says that now, in place of the pinned-band wording.
• DropGzipCopies conflict: took Keep the gzip copy of dotnet.native.wasm #19's version (keep the dotnet.native.wasm gzip copy) and its condition is now net10.0-browserwasm.

Checked:

• The PR build passes on this branch: checks, desktop, android, ios and browserwasm.
• On a local SDK 10.0.401, with nothing pinned:
  • SampleLinks and the source-viewer self-test pass.
  • The desktop head builds.
  • The deploy's AOT publish succeeds. index.html and web.config are there, and dotnet.native.<hash>.wasm.gz is the only .gz left.

The "global.json" and "Team setup" parts of the description above still describe the 10.0.1xx pin.

🤖 Generated with Claude Code