IL2026/IL2104 trim analysis warnings on TodoApp.Avalonia.iOS build

[adrianhall]

Summary

Surfaced by the new mobile CI added in #511 (PR #519), specifically the TodoApp.Avalonia.iOS build (net10.0-ios). The build succeeds, but produces two categories of IL-trimmer warnings:

1. IL2026 (trim analysis, points at our own source) - 2 distinct findings, each reported twice (initial compile pass + final build summary):

   samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia/App.axaml.cs(57,9): Trim analysis warning IL2026:
   TodoApp.Avalonia.App.OnFrameworkInitializationCompleted(): Using member
   'Avalonia.Data.Core.Plugins.BindingPlugins.DataValidators.get' which has 'RequiresUnreferencedCodeAttribute'
   can break functionality when trimming application code. PropertyAccessors might require unreferenced code.
   
   samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia/Database/AppDbContext.cs(16,69): Trim analysis warning IL2026:
   TodoApp.Avalonia.Database.AppDbContext.AppDbContext(DbContextOptions<AppDbContext>): Using member
   'Microsoft.EntityFrameworkCore.DbContext.DbContext(DbContextOptions)' which has 'RequiresUnreferencedCodeAttribute'
   can break functionality when trimming application code. EF Core isn't fully compatible with trimming, and
   running the application may generate unexpected runtime failures.
   

2. IL2104 (rollup, points at third-party assemblies) - 9 occurrences, one per referenced assembly that itself "produced trim warnings": System.Private.CoreLib, Avalonia.Diagnostics, Avalonia.DesignerSupport, CommunityToolkit.Datasync.Client, Microsoft.EntityFrameworkCore.Relational, Microsoft.EntityFrameworkCore.Sqlite, Microsoft.EntityFrameworkCore, Microsoft.Spatial, Microsoft.Data.Sqlite. These are all downstream consequences of the two root findings above (once EF Core/Avalonia's own trim-unsafe APIs are pulled in, every assembly in that call graph gets flagged) - none of them point at anything in samples/.

Root cause

net10.0-ios triggers .NET's IL trim analyzer at build time (not just publish), because iOS app projects are marked trimmable by the SDK by default (mobile platforms assume eventual AOT/trimmed publishing). Neither of the two direct findings are bugs in this repo's sample code - they're both hitting framework APIs that their own maintainers have explicitly marked [RequiresUnreferencedCode]:

• Avalonia's compiled-binding validator plugin (BindingPlugins.DataValidators) is inherently reflection-based.
• EF Core's DbContext(DbContextOptions) constructor path is explicitly and permanently documented as not fully trim-compatible (see https://aka.ms/efcore-docs-trimming) - this is a known, long-standing EF Core limitation, not something fixable from a consuming app.

Should we fix the code, or turn off trim analysis? (analysis requested)

Recommendation: turn off trim analysis for this sample, don't chase the framework warnings.

Reasoning:

• This repository's CI only runs dotnet build, never dotnet publish -p:PublishTrimmed=true for any sample (confirmed: no PublishTrimmed/SelfContained is set anywhere for TodoApp.Avalonia.iOS.csproj). So today, trim analysis on this project is purely diagnostic noise - no actual trimming/linking happens, and no app is ever shipped from this pipeline.
• Both underlying IL2026s originate from idiomatic, documented usage of Avalonia data binding and EF Core's DbContext constructor - exactly how the tutorial in docs/samples/todoapp/avalonia.md teaches readers to wire up the sample. Avoiding these APIs (e.g., hand-rolling binding without BindingPlugins, or restructuring AppDbContext to dodge the DbContext(DbContextOptions) ctor) would fight the frameworks' own recommended patterns for the sake of a warning that has no functional consequence in a build-only pipeline, and would make the sample worse as a teaching example.
• EF Core's trim-incompatibility here isn't something an app author can fully resolve without EF Core itself changing (tracked upstream by the EF Core team, not fixable in samples/).
• There's already precedent in this repo for explicitly opting out of trim analysis noise once a project accepts it won't be fully trimmed: samples/todoapp/TodoApp.Uno/TodoApp.Uno/Properties/PublishProfiles/win-x86.pubxml sets <SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings> alongside <TrimMode>partial</TrimMode>.

Suggested fix: add <SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings> to samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.iOS/TodoApp.Avalonia.iOS.csproj (and audit whether TodoApp.Avalonia.Android.csproj / TodoApp.MAUI.csproj's iOS head need the same treatment - Android didn't surface these warnings in this run, but MAUI's iOS head should be checked once its trim behavior is verified). If this sample is ever changed to actually ship a trimmed/AOT iOS build via dotnet publish, that's a separate, much larger effort (would need real device/simulator testing of PublishTrimmed/TrimMode, not just warning suppression) and should be tracked as its own issue at that time - don't conflate "quiet the analyzer for an untrimmed build-only sample" with "make this app genuinely trim-safe."

Verification

• Should be a single-property change; re-run dotnet build samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.iOS/TodoApp.Avalonia.iOS.csproj --configuration Release (macOS/Xcode required) and confirm the IL2026/IL2104 warnings are gone while the build still succeeds.

Related

• Add CI workflow to build mobile /samples heads: Android, iOS, Uno (Phase 3 of #509) #511 / PR ci: add build-samples workflow for Phase 3 mobile heads (#511) #519 - Phase 3 samples CI rollout, where this was surfaced.