Add support for .NET 11 RC 3 (#13310)

.devcontainer/devcontainer.json

@@ -14,7 +14,7 @@
     },
     "ghcr.io/devcontainers/features/node:2": { "version": "24" }
   },
-  "image": "mcr.microsoft.com/dotnet/sdk:10.0.403",
+  "image": "mcr.microsoft.com/dotnet/sdk:11.0.100-rc.3",
   "postStartCommand": "dotnet workload install wasm-tools && dotnet dev-certs https --trust",
   "waitFor": "onCreateCommand",
   "customizations": {

.github/agents/dependency-update.md

@@ -65,25 +65,25 @@ for the oldest supported SDK:
 | `System.Reflection.Metadata` | 1.6.0 | `Bit.BlazorUI.Build` |
 
 **TFM-conditioned floors — only the highest band moves.** A multi-targeted library pins the `.0` of
-each band it supports, because the pin *is* the consumer's minimum runtime. Raising 8.0.0 to 8.0.x
+each band it supports, because the pin *is* the consumer's minimum runtime. Raising 10.0.0 to 10.0.x
 raises that minimum for no gain.
 
 ```xml
-<PackageReference Include="Microsoft.JSInterop" Version="8.0.0" Condition="'$(TargetFramework)' == 'net8.0'" />
+<PackageReference Include="Microsoft.JSInterop" Version="10.0.0" Condition="'$(TargetFramework)' == 'net10.0'" />
 ```
 
 Applies to `Bit.Besql` (JSInterop, Components.WebAssembly, EF Core Sqlite), `Bit.BlazorUI` /
 `.Assets` / `.Extras` / `.Legacy`, `Bit.Bswup` and `Bit.Butil` (Components.Web), and the
 `BlazorEmpty` template.
 
 The rule keys on the `.0` in a *shipped library*. A TFM-conditioned pin at a concrete patch —
-`Bit.BlazorUI.Tests` on Components.WebView `8.0.x` / `9.0.x` / `10.0.x` — is not a floor: nothing
+`Bit.BlazorUI.Tests` on Components.WebView `10.0.x` — is not a floor: nothing
 consumes a test project, so every band takes the newest patch of its own band. Likewise a lone
 `10.0.0` sitting among `10.0.11` siblings in `Directory.Packages.props` is staleness, not intent.
 
-**Version ranges stay.** `[8.0.0,9.0.0)` is a compatibility contract, not a pin.
+**Version ranges stay.** `[10.0.0,11.0.0)` is a compatibility contract, not a pin.
 
-**`Bit.*` self-references track the in-development version**, currently `10.7.0`. Never read
+**`Bit.*` self-references track the in-development version**, currently `11.0.0-pre-15`. Never read
 these off nuget.org — the published `latest` is behind the working tree by design, and unrelated
 higher-numbered lines exist there.
 
@@ -108,13 +108,28 @@ gh api "repos/<owner>/<repo>/git/trees/<sha>?recursive=1" --jq '[.tree[]|select(
 A non-zero count on a JavaScript action that vendors `node_modules` means it will not stage. This is
 worth checking for *any* action bump, not just this one — it is invisible in the release notes.
 
-**A MAUI bump needs one MAUI build.** MAUI's resizetizer bundles an `Svg.Skia`, and from 10.0.101 to
-10.0.110 that `Svg.Skia` called a SkiaSharp overload missing from the SkiaSharp next to it, so any SVG
-with a `<filter>` failed the build with `MAUIR0001` /
-`MissingMethodException: SKImageFilter.CreateMatrixConvolution`
-([dotnet/maui#38319](https://github.com/dotnet/maui/issues/38319)). The app icons of the Boilerplate
-and the BlazorUI demo have one, so before moving MAUI, build a MAUI app with the Boilerplate's
-`appicon.svg` as its icon, for any target.
+**MAUI's resizetizer breaks on SVG filters.** MAUI 10.0.101 to 10.0.110 and 11.0.0-rc.2 bundle an `Svg.Skia` that
+calls a SkiaSharp overload missing from the SkiaSharp next to it, so any SVG it resizes that has a `<filter>` fails
+the build with `MAUIR0001` / `MissingMethodException: SKImageFilter.CreateMatrixConvolution`
+([dotnet/maui#38319](https://github.com/dotnet/maui/issues/38319)). 10.0.120 fixed it for .NET 10, and a .NET 10
+Boilerplate project takes develop's MAUI. On this branch MAUI can't stay behind for .NET 11: a MAUI built for an
+older preview doesn't compile against the newer preview's Android workload (CS1705 on `Java.Interop`). So MAUI
+follows the MAUI manifest of the SDK's newest workload set (`Microsoft.NET.Workloads.<band>` on NuGet) here, which
+can stay on the previous release candidate when a new one ships, together with Android and iOS; then MAUI stays
+too. The app icons of the Boilerplate and the BlazorUI demo carry no drop shadow (their
+`<filter>`) until a .NET 11 MAUI builds an app with the Boilerplate's `appicon.svg` as its icon.
+
+**bit Boilerplate builds for .NET 10 and .NET 11.** Its `framework` option picks one; the template's own tree is
+the .NET 11 project. In its `Directory.Packages.props`, a package whose 11.x build has no `net10.0` assets has a
+version in each of the two framework groups at the end of the file: the 11.x one, and a 10.x one that moves within
+10.x. So do the `Microsoft.Extensions.*` packages, although their 11.x builds have `net10.0` assets: they bring
+`Microsoft.Extensions.Logging.Abstractions` 11 into the .NET 10 server projects, whose targets file then overrides
+the one `Microsoft.Extensions.Telemetry.Abstractions` turns the framework's logging generator off with, depending
+on import order, and the build fails with CS0757. Every other package takes one version for both. The few literals that differ per framework are switch
+symbols in `template.json` (the SDK and its `rollForward`, the dev container image, the `dotnet-ef` version, the
+runner image), so they move together with the files they replace. A template line that came over from develop
+carries develop's .NET 10 value of such a literal, which no symbol maps, so look for the .NET 10 values in the
+template's files and give them the .NET 11 one.
 
 **`Xamarin.Firebase.Messaging` is held at 125.1.1.** 125.1.2 pulls `Xamarin.AndroidX.Fragment` 1.9.0
 (through `GooglePlayServices.Base` 118.10.1), which absorbed the ktx classes, while the rest of the
@@ -124,10 +139,22 @@ the graph already brings `Fragment.Ktx` 1.9.0 (an empty stub), rather than pinni
 `Xamarin.GooglePlayServices.Auth.Api.Phone` is held at 118.3.1 for the same reason: 118.3.1.1 pulls
 `GooglePlayServices.Basement` 118.10.0.3, which brings Fragment 1.9.0.
 
-**Linux runners are held at `ubuntu-24.04`**, in the GitHub workflows and the Azure DevOps `vmImage`.
-`ubuntu-26.04` defaults to JDK 25 (`(default)` in the image readme's Java table), and .NET for Android
-10 accepts up to 21 (`LatestSupportedJavaVersion` 21.0.99), so every Android build there fails. .NET 11
-raises the limit to 25.0.99; move the runners together with the .NET 11 move.
+**EF Core in the Boilerplate follows its PostgreSQL provider.** A preview of
+`Npgsql.EntityFrameworkCore.PostgreSQL` asks for one exact EF Core version, and a provider built for another
+one fails at runtime ("Method not found"). So the Boilerplate's EF Core stays on the version the newest Npgsql
+names, together with every package that requires it (`Microsoft.EntityFrameworkCore.*`,
+`Microsoft.AspNetCore.Identity.EntityFrameworkCore`, `Microsoft.AspNetCore.DataProtection.EntityFrameworkCore`,
+`Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore`) and its `dnx dotnet-ef` calls, while the
+rest of ASP.NET Core moves on. A NU1608 on Npgsql in a restore means this was missed. A shipped library's EF Core
+floor in the band the Boilerplate uses can't go above that version either: `Bit.Besql`'s raised the offline
+database's Sqlite above it, and the project's restore failed with NU1605.
+
+**Linux runners are on `ubuntu-26.04`**, in the GitHub workflows and the Azure DevOps `vmImage`. It
+defaults to JDK 25 (`(default)` in the image readme's Java table), which .NET for Android accepts from .NET 11
+RC2 on (`LatestSupportedJavaVersion` 25.0.99 in `Xamarin.Android.Common.props.in`). develop stays on
+`ubuntu-24.04`, since .NET for Android 10 accepts up to 21, so a runner pin that comes over from develop moves
+to `ubuntu-26.04` here, except in the jobs that build a .NET 10 Boilerplate project (the Todo and Sales CDs), which
+keep develop's runners.
 
 When a held pin's rationale no longer holds — the oldest supported SDK moved, TS 7 was adopted
 repo-wide — say so in the report rather than acting on it.
@@ -253,14 +280,16 @@ There are no `.config/dotnet-tools.json` manifests any more: every tool is run w
 <package>@<version>`, so the pins live in the workflow and doc lines that call them (`grep -rn "dnx
 .*@"`). `vpk` must equal the `Velopack` PackageReference version in the same project — Velopack
 requires the CLI and the library to match, and this has drifted before. `dotnet-ef` should equal the
-EF Core package version. Likewise the `npx playwright@<version>` command in the Boilerplate's two
+EF Core package version of the project it runs on: the .NET 11 one in the template's files, the .NET 10 one in
+`template.json`'s `efToolVersion` and in the Todo CD. Likewise the `npx playwright@<version>` command in the Boilerplate's two
 `.runsettings` (`src/Tests` and `src/Internal/Boilerplate.Tests.E2E`) must equal
 `Microsoft.Playwright.MSTest.v4`: a remote Playwright server of any other version refuses the client, and
 every test that runs on it fails at connect.
 
-`src/global.json` is `rollForward: disable` and tracks the newest SDK. The two template
-`global.json` files are `10.0.100` + `latestFeature` deliberately — they must accept any 10.0.x on a
-consumer's machine. Do not "update" them.
+`src/global.json` is `rollForward: disable` and tracks the newest SDK. While .NET 11 is a release
+candidate, the two template `global.json` files pin the same RC SDK, also `rollForward: disable`, and
+move with it. Once .NET 11 ships they go back to `11.0.100` + `latestFeature`, so they accept any
+11.0.x on a consumer's machine. A .NET 10 project gets `10.0.100` + `latestFeature` from `template.json`.
 
 ### Container images
 

.github/agents/test-platform.md

@@ -121,9 +121,9 @@ websites - is checked. Every command prints what it checked and exits non-zero o
 | `windows [-Force]` | Opens each Windows app that is behind and taps its version, which updates it and restarts it. |
 | `e2e [-Stage <stages>] [-Filter <filter>] [-PrereleasePackages]` | Signs the global admin in once, then runs the E2E suite stage by stage like `RunTests.bat` - skipping the mac's stages when its Playwright server is down or on another version - keeping each stage's log and TRX. With `-PrereleasePackages`, it builds the suite with the Bit packages of the newest Prerelease nuget packages run. |
 | `mcp [-McpVersion <x.y.z>] [-Tool <name> -Arguments <json>] [-AllLibraries]` | One `tools/list` or `tools/call` on `https://bitplatform.dev/mcp`. `-AllLibraries` lists every bit library's tools, as the website's chat does; without it BlazorUI's and Butil's are the only library tools listed. |
-| `devcontainer [-Sha <sha> [-PrereleasePackages]] [-Keep]` | Creates a project with `bit new`, brings its dev container up with the devcontainers CLI and runs `bit doctor` in it, with bit and the template from that commit or from nuget.org. Then removes the container, its volumes and its image, and keeps the logs. |
-| `aspire [-Sha <sha> [-PrereleasePackages]] [-Keep]` | Creates a project with `bit new` the same way and runs its Aspire app host three times with `dotnet run`: the second run must reuse the first one's containers, they must stop once the app host has sat idle for its idle time, and the third run must bring them back on the same volumes. Then removes the project, its containers and their volumes, and keeps the logs. |
-| `agents [-Sha <sha> [-PrereleasePackages]] [-Scenario <ids>] [-Model <models>] [-Long] [-Keep]` | Creates a project with `bit new` as users get it and hands each scenario of `agent-scenarios.json` to a headless Claude Code that sees nothing but a copy of that project, then checks which skills it read, which tools it called and which files it changed after each turn. Keeps the transcripts and final messages. |
+| `devcontainer [-Sha <sha> [-PrereleasePackages]] [-Framework <tfm>] [-Keep]` | Creates a project with `bit new`, for the template's default .NET or the one `-Framework` names, brings its dev container up with the devcontainers CLI and runs `bit doctor` in it, with bit and the template from that commit or from nuget.org. Then removes the container, its volumes and its image, and keeps the logs. |
+| `aspire [-Sha <sha> [-PrereleasePackages]] [-Framework <tfm>] [-Keep]` | Creates a project with `bit new` the same way and runs its Aspire app host three times with `dotnet run`: the second run must reuse the first one's containers, they must stop once the app host has sat idle for its idle time, and the third run must bring them back on the same volumes. Then removes the project, its containers and their volumes, and keeps the logs. |
+| `agents [-Sha <sha> [-PrereleasePackages]] [-Framework <tfm>] [-Scenario <ids>] [-Model <models>] [-Long] [-Keep]` | Creates a project with `bit new` as users get it and hands each scenario of `agent-scenarios.json` to a headless Claude Code that sees nothing but a copy of that project, then checks which skills it read, which tools it called and which files it changed after each turn. Keeps the transcripts and final messages. |
 
 ## 1. The CI run
 
@@ -365,7 +365,8 @@ Triage every failure:
    tell flaky from broken. A stage's console log counts every failed attempt of a test that retries, its TRX only
    the last one: a test the TRX shows passed failed once and passed on its retry. Compare a failure only with earlier
    runs against a deployment from the same branch: the demos run whichever branch the last CD built, and the
-   branches differ in their .NET.
+   branches differ in their .NET. On one branch the demos can differ too: each demo's CD names the `--framework` it
+   builds with, so a failure in one app and not another may be the .NET version rather than the app.
 2. Read the server's side. The demo backends run on this machine and log to the Windows **Application** event log,
    source `.NET Runtime`. How much gets there is each site's own `Logging` section in its server-owned
    `appsettings.json` under `C:\inetpub\<site>`: the Boilerplate backends log from Information up, the platform
@@ -394,9 +395,9 @@ no `Content-Length`, was compressed again on the way. Compare the libraries' ass
 with a publish of the commit the expected sizes were measured on. The service worker's own scripts, its asset list
 included, report no size to Playwright, so the total leaves them out.
 
-Two failures on .NET 11 are known gaps of third-party libraries; report them as known and don't triage them: the
-template's MySQL provider doesn't work there (All CI keeps its MySQL job off), and CommunityToolkit.Datasync doesn't
-sync, so the offline Todo test that waits for an item added offline to reach the server fails every time. Check them
+Two gaps of third-party libraries on .NET 11 are known: the template's MySQL provider doesn't work there, and
+CommunityToolkit.Datasync doesn't sync. That is why All CI's MySQL job and the offline Todo demo build .NET 10
+projects. A .NET 11 project that uses either fails by design: report it as known and don't triage it. Check them
 again once those libraries support .NET 11.
 
 **A fix is proven only by the next CD.** The suite tests the deployed build, so a fix to the template or to a demo
@@ -533,8 +534,10 @@ alive for its idle time. `aspire` checks that the way a developer meets it:
 - `-Sha` and `-PrereleasePackages` work as for `devcontainer`. With `-PrereleasePackages` the project restores into a
   packages folder of its own, since this machine's cache may hold nuget.org's build of the same version; without it
   the Bit packages come from nuget.org at the version the template asks for. The project's `global.json` asks for
-  the repository's SDK, which needs the workloads the template's clients build with (`wasm-tools`): an SDK that
-  Visual Studio installed brings only its own.
+  the SDK of its .NET version, which needs the workloads the template's clients build with (`wasm-tools`): an SDK
+  that Visual Studio installed brings only its own.
+- Without `-Framework`, both `aspire` and `devcontainer` create a project for the template's default .NET. When a
+  change touches what differs between the .NET versions, run `aspire` once with each.
 - It takes about half an hour, most of it the idle wait, and a few GB of Docker's memory while the app runs.
   Start it in the background as soon as its packages exist and this machine has several GB free, and never next to
   `devcontainer` or the Android stage. A second run can start once the first is in its idle wait. Its containers

.github/agents/test-platform/test-platform.ps1

@@ -27,6 +27,7 @@
     agents    Creates a project with bit new, then hands each scenario of agent-scenarios.json to a headless Claude Code
               that sees nothing but that project, in a copy of its own, and checks what it did: which skills it read,
               which tools it called and which files it changed after each turn. -Sha and -Keep as above.
+              All three create the project for the template's default .NET version unless -Framework names another.
 
     What is deployed where is read from those CD workflows and from the E2E suite's DeployedApps.cs and
     RunTests.bat rather than repeated here, so this script follows them.
@@ -105,7 +106,11 @@ param(
     # agents: runs one scenario of the lab that -Lab names; the command starts these itself.
     [switch] $Worker,
 
-    [string] $Lab
+    [string] $Lab,
+
+    # devcontainer, aspire, agents: the project's --framework; the template's default when omitted.
+    [ValidateSet('net10.0', 'net11.0')]
+    [string] $Framework
 )
 
 $ErrorActionPreference = 'Stop'
@@ -965,7 +970,7 @@ function Install-BitUnderTest([string] $lab) {
     }
     else {
         Write-Host 'Installing bit from nuget.org...'
-        dotnet tool install Bit.Cli --tool-path $tools --version 10.7.0 | Out-Null
+        dotnet tool install Bit.Cli --tool-path $tools --version 11.0.0-pre-15 | Out-Null
     }
 
     if ($LASTEXITCODE -ne 0) {
@@ -1038,10 +1043,11 @@ function New-BitProject([string] $lab, $bit, [string] $name, [string[]] $options
     Push-Location $lab
 
     $templateArguments = $bit.TemplateArguments
+    $frameworkArguments = $Framework ? @('--framework', $Framework) : @()
 
     try {
         $setupArguments = $setup ? @('--no-tools', '--no-workloads', '--ide', 'none') : @('--no-setup')
-        & $bit.Path new $name --yes --no-open --no-trust @setupArguments @options @templateArguments *> (Join-Path $lab 'new.log')
+        & $bit.Path new $name --yes --no-open --no-trust @setupArguments @options @frameworkArguments @templateArguments *> (Join-Path $lab 'new.log')
         $newExitCode = $LASTEXITCODE
     }
     finally {

.github/copilot-instructions.md

@@ -2,8 +2,8 @@
 
 ## Key Technologies
 
-- **C# 13.0**
-- **ASP.NET Core 9.0**
+- **C# 14.0**
+- **ASP.NET Core 10.0**
 - **Blazor**: Component-based web UI framework
 - **.NET MAUI Blazor Hybrid**: Cross-platform app development
 - **ASP.NET Core Identity**: Authentication and authorization