feat: add support for .NET 11 RC 1

[jamescrosswell]

Follows #5529 (preview 7) through to RC 1, targeting version7.

Closes #5552

The version bump

	preview 7	RC 1
SDK (global.json)	11.0.100-preview.7.26381.103	11.0.100-rc.1.26425.128
workload set (global.json)	11.0.100-preview.7.26410.2	11.0.100-rc.1.26458.5
prerelease Microsoft.* package refs	11.0.0-preview.7.26381.103	11.0.0-rc.1.26425.128

RC 1 moved no TFMs — macios dotnet-11.0.1xx-rc1-12193 still publishes net11.0-ios26.5/net11.0-maccatalyst26.5 and android 37.0.0-rc.1.2257 is still API 37.0 — so Directory.Build.props' TFM block, every project and sample that derives from it, and all the Verify snapshots are untouched. Xcode 26.6 (which RC 1 requires), platforms;android-37.0 and 10.0.x in dotnet-version were all already in place from #5529.

The runtime-deps container pins stay on the 11.0-preview-* tags. MCR now also publishes non-preview 11.0-resolute-chiseled/11.0-alpine, but runtime-deps carries OS-level dependencies rather than the runtime, so the distro is what matters and the preview tags still resolve correctly. Per the CONTRIBUTING.md checklist these get blanked at GA, not at RC.

The interesting part: four things RC 1 broke

Each was isolated the same way rather than guessed at - swap global.json back to preview 7, rebuild the single project and TFM that failed, compare. That technique is now written into CONTRIBUTING.md, along with rows for all four.

1. CS0400 in the Android bindings — blocked every job. The android 37 generator keeps methods whose parameter types are unbound, where android 36 dropped them before the Metadata.xml transforms ran (the overload is in api.xml.class-parse but not api.xml). TombstoneParser.parse(Tombstone) takes a type from epitaph, which we reference with Bind="false", so the generated binding emitted an unresolvable global::Com.Abovevacant.Epitaph.Core.Tombstone. Dropped the overload; we never call TombstoneParser from C# and the parameterless parse() is unaffected.

Scoped to net11+ in its own transform file, because the Android SDK auto-globs Transforms/**/*.xml into every TFM and the entry warns BG8A00: matched no nodes on android 36 - which reads exactly like a broken XPath to whoever hits it next.

2. CsWinRT1032 on both -windows TFMs. RC 1 ships a CsWinRT that rejects a collection expression whose target is a non-mutable interface, because the synthesised type isn't trim/AOT-safe for WinRT. BreadcrumbEvent.extraData is params IEnumerable<(string key, string value)>, so four gesture breadcrumbs tripped it. Cast to a concrete array rather than changing the public signature. Note this hits net10.0-windows too - 8 errors under RC 1, 0 under preview 7, same source.

3. IL2037 ×154 when linking an Apple app. MAUI 11 RC 1's own Compatibility handler descriptors name members that don't resolve. ILLinkTreatWarningsAsErrors defaults to TreatWarningsAsErrors, so these failed the build. Demoted via WarningsNotAsErrors rather than silenced with NoWarn, so it stays visible and gets removed once MAUI fixes the descriptors. We ship no ILLink descriptors of our own, so every IL2037 is external by construction; Sentry.TrimTest and Sentry.MauiTrimTest opt out of Directory.Build.props, so the Trim analysis job keeps the strict setting.

4. Apple symbol upload silently stopped uploading framework symbols — this one affects customers.

Sentry.targets collected the framework assemblies' PDBs (Microsoft.iOS, Microsoft.Maui.*) from $(IntermediateOutputPath)linked. RC 1 renamed that directory to postprocessed-assemblies. The glob is Exists()-guarded, so nothing errored - six fewer debug files were uploaded and framework frames stopped symbolicating.

	linked/	postprocessed-assemblies/
preview 7	11 PDBs	absent
RC 1	absent	the identical 11 PDBs

The names are mutually exclusive per SDK, so probing both covers every supported iOS SDK and double-counts nothing. This ships in buildTransitive, so it would have hit any customer building a .NET 11 Apple app with Sentry, not just this repo - the same class of silent breakage as the Native AOT _CopyAotSymbols change in #5529.

Worth flagging in review: it was caught only because integration-test/cli.Tests.ps1 asserts the exact upload set. Both probes remain Exists()-guarded, so the next rename will also fail silently in production and show up only as that test failing. I've said so in a comment above the probes; please don't loosen that assertion to a count.

Known gap, unchanged from #5529

Sentry.MauiTrimTest targets only net10.0-android36.0;net10.0-ios26, so MAUI trim analysis doesn't cover net11.0 at all - which is a shame given #3 above was a MAUI trimming regression. Left alone here since widening it is a scope decision rather than part of an RC bump, but it may be worth a follow-up.

Separately, dotnet publish test/Sentry.MauiTrimTest -f net10.0-ios26 can't be built on a machine set up for this branch: it pins Xcode 26.0 while RC 1's net11.0-ios26.5 requires the 26.6 that CI pins. CI has that publish commented out already (provisioning profiles), so nothing is lost.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (version7@21f45f0). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...Maui/Internal/MauiGestureRecognizerEventsBinder.cs	0.00%	5 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             version7    #5566   +/-   ##
===========================================
  Coverage            ?   74.67%           
===========================================
  Files               ?      515           
  Lines               ?    18892           
  Branches            ?     3684           
===========================================
  Hits                ?    14107           
  Misses              ?     3903           
  Partials            ?      882           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jamescrosswell]

Why build-sentry-native.ps1 passes -T v143

• sentry-native.lib ships in the Sentry NuGet package. It gets linked into customers' Native AOT apps by whichever MSVC linker they have installed.
• MSVC compatibility only works in one direction. A linker can consume libraries built by the same or an older toolset, but not a newer one. A lib built with VS 2026's MSVC (14.5x) may fail to link for customers still on VS 2022 (MSVC 14.4x), which is still a supported toolset for .NET 8 and 9.
• We can't keep VS 2022 by choosing runner images. windows-latest and windows-2025 already run the VS 2026 image, and windows-11-arm switches between September 21 and 30 ([Windows] The windows-11-arm image label will use Windows 11 Arm64 with Visual Studio 2026 image in September 2026 actions/runner-images#14602).
• The VS 2026 images still install the VS 2022 toolset side by side (Microsoft.VisualStudio.Component.VC.14.44.17.14.x86.x64 and .ARM64). -T v143 tells CMake's Visual Studio generator to compile with it, so the shipped lib stays linkable by both VS 2022 and VS 2026.
• Everything else builds with VS 2026, including the Native AOT publishes in the integration tests. .NET 10+ Native AOT requires VS 2026 (Native AOT publish for win-arm64 fails with LNK1322 (Cortex-A53 erratum 843419) on .NET 11 RC 1 dotnet/runtime#133835).

Drop -T v143 once VS 2022 is out of support, or if the v143 component disappears from the runner images.