fix: suppress IL2026/IL2104 trim analysis warnings on mobile TodoApp samples#531
Merged
Merged
Conversation
added 4 commits
July 10, 2026 12:00
…samples net10.0-ios (and mobile TFMs generally) enable the IL trim analyzer during 'dotnet build', not just 'dotnet publish', because these SDKs are marked trimmable by default. This surfaced IL2026/IL2104 warnings on TodoApp.Avalonia.iOS pointing at documented, trim-unsafe framework APIs (Avalonia's BindingPlugins.DataValidators, EF Core's DbContext(DbContextOptions) ctor) - not bugs in the sample code. The CI pipelines for these samples only ever run 'dotnet build', never 'dotnet publish -p:PublishTrimmed=true', so no actual IL trimming/linking occurs; the analyzer is pure diagnostic noise here. Add <SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings> to: - TodoApp.Avalonia.iOS.csproj (the confirmed, reported case) - TodoApp.Avalonia.Android.csproj (same shared code path, precautionary) - TodoApp.MAUI.csproj, scoped to the net10.0-ios TFM only Per Microsoft.NET.ILLink.targets, this property also sets EnableTrimAnalyzer=false, which disables the analyzer pass itself (not just its warning output), avoiding any analyzer-related build-time cost in addition to the noise. Fixes CommunityToolkit#521
Watching PR CommunityToolkit#531's CI run revealed a distinct, more expensive problem than the trim-analyzer warnings fixed in the prior commit: net10.0-ios Release builds run the actual ILLink trimmer (not just the analyzer) even for a plain 'dotnet build' against a simulator RID. 'Optimizing assemblies for size' / 'IL stripping assemblies' dominates ~90% of the build time, stretching the todoapp-avalonia/ios and todoapp-maui/ios jobs to 15+ minutes each, while the equivalent Android jobs for the same samples complete in ~3.5 minutes total. Since these CI jobs only ever run 'dotnet build' as a compile sanity check - never 'dotnet publish' - there is no benefit to actually linking here. Pass -p:PublishTrimmed=false on the dotnet build command line for the two affected 'ios' jobs only: - build-samples-todoapp-avalonia.yml - build-samples-todoapp-maui.yml Deliberately a CI-only override (not a .csproj change), so a developer following the tutorial who runs a real 'dotnet publish' still gets the platform's normal trimming default and app size. Related to CommunityToolkit#521
…builds The prior commit's -p:PublishTrimmed=false broke both iOS jobs immediately (confirmed via CI run 29089733157): the iOS SDK hard-rejects it - error: iOS projects must build with PublishTrimmed=true. Current value: false. Set 'MtouchLink=None' instead to disable trimming for all assemblies. [Xamarin.Shared.Sdk.targets(304,3)] Switch to the SDK-blessed -p:MtouchLink=None, which keeps the mandatory PublishTrimmed=true while skipping the actual link/strip work that was dominating build time.
Per https://blog.verslu.is/maui/exclude-assemblies-from-trimming/, Debug configuration avoids .NET's IL trimming/AOT machinery entirely, which is a simpler and more broadly effective fix than the prior MtouchLink=None command-line workaround (removed here - no longer needed). These CI workflows are build-only compile sanity checks - none of them publish or ship an app - so there is no reason to pay for Release-only optimizations (trimming, AOT) anywhere in this matrix. Switch DOTNET_CONFIGURATION from Release to Debug across all build-samples-*.yml workflows for consistency, not just the two mobile ones that were observed to be slow. build-library.yml and build-template.yml are intentionally left at Release, since those build the actual shipped library and dotnet template, not a sample. Related to CommunityToolkit#521
This was referenced Jul 10, 2026
TodoApp.Uno: trim analysis warnings (IL2026/IL2104/IL2121) on browserwasm/ios/maccatalyst heads
#534
Closed
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 was referenced Jul 11, 2026
Merged
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 #521.
net10.0-ios(and mobile TFMs generally) enable the IL trim analyzer duringdotnet build— not justdotnet publish— because these SDKs mark projects trimmable by default. This surfacedIL2026/IL2104warnings on theTodoApp.Avalonia.iOSbuild (surfaced by the mobile CI added in #511 / PR #519), pointing at documented, trim-unsafe framework APIs:BindingPlugins.DataValidators(inherently reflection-based, by design)DbContext(DbContextOptions)constructor (explicitly documented as not fully trim-compatible: https://aka.ms/efcore-docs-trimming)Neither is a bug in the sample code — both are idiomatic, documented usage of their respective frameworks, exactly as taught in
docs/samples/todoapp/avalonia.md.Why suppress rather than fix the code
This repo's CI only ever runs
dotnet buildfor these samples (seebuild-samples-todoapp-avalonia.yml/build-samples-todoapp-maui.yml) — neverdotnet publish -p:PublishTrimmed=true. So today, trim analysis on these projects is purely diagnostic noise: no actual IL trimming/linking ever happens, and no app is shipped from this pipeline. Avoiding the flagged APIs would mean fighting Avalonia/EF Core's own recommended patterns for the sake of a warning with no functional consequence in a build-only pipeline, and would make the samples worse as teaching examples.Changes
Added
<SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings>:samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.iOS/TodoApp.Avalonia.iOS.csproj— the confirmed, reported case.samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.Android/TodoApp.Avalonia.Android.csproj— same shared code path (App.axaml.cs/AppDbContext.cs) is compiled under this TFM too; added precautionarily even though Android didn't surface the warning in the CI run that filed the issue.samples/todoapp/TodoApp.MAUI/TodoApp.MAUI.csproj— scoped to thenet10.0-iosTFM only (via theGetTargetPlatformIdentifierconditional pattern already used elsewhere in this file), since the Android/Windows heads weren't confirmed to have the warning.Each edit includes a comment explaining the root cause and linking back to #521.
Bonus: this also avoids the analyzer's build-time cost, not just its warning output
Per the actual
Microsoft.NET.ILLink.targetsshipped in the SDK:Setting
SuppressTrimAnalysisWarnings=truealso setsEnableTrimAnalyzer=false(since we don't setEnableTrimAnalyzerexplicitly ourselves), which disables the analyzer pass itself rather than merely hiding its output. Separately, the actualILLinklinking task (the potentially slow part) is only ever wired into thepublishpipeline, notbuild— so it was never running here in the first place.Testing
dotnet buildon the sharedTodoApp.Avalonia.csprojandTodoApp.Avalonia.Desktop.csproj— succeeded (1 pre-existing, unrelated nullable warning).dotnet restore/dotnet build --configuration ReleaseonDatasync.Toolkit.sln— succeeded, 0 warnings/0 errors. (This solution doesn't include the edited sample projects, confirming no impact on the core library.)dotnet test Datasync.Toolkit.sln --configuration Release—CommunityToolkit.Datasync.Client.Test: 1432/1432 passed.CommunityToolkit.Datasync.Server.Testhad pre-existing, environment-only failures (no local Docker daemon; that suite depends on TestContainers) — confirmed identical failure count with the changes stashed out, so unrelated to this PR.net10.0-ios/ MAUI-iOS heads to visually confirm the warnings disappear (no Xcode/iOS workload available locally) — deferred to this repo's CI, which pins the exact Xcode/workload versions that originally surfaced the warnings.Related