Address Trim warnings and prevent future regressions

[jamescrosswell]

Resolves #3808:

• Unable to publish AOT compiled net9.0-ios apps #3808

Summary

To get useful trim analysis when building libraries we need a test app that shows all warnings.

In this PR we've added test/Sentry.TrimTest/Sentry.TrimTest.csproj to serve as the test app that will produce said warnings for most of the sentry packages. We've also added test/Sentry.MauiTrimTest/Sentry.MauiTrimTest.csproj to detect trim warnings for code targeting android and iOS (in the Sentry.Maui and Sentry.Bindings.* packages).

Additionally, a new job has been added to CI to publish those two test apps. If the publish attempts succeed without error, we should be trim compatible.

Note to Reviewers

This looks like a 9k line PR. However, most of the "additions" are in test/Sentry.MauiTrimTest/Resources/Fonts/FluentUI.cs which is just part of the MAUI template (and can be ignored).

Merge Note

This PR should also be merged in the Ben.Demystifier submodule when this PR is accepted/merged:

• Make trim warnings more specific Ben.Demystifier#7

Sentry.Maui trimming limitations

We're using reflection to read the values of some internal properties on event args (so we can drop breadcrumbs). When apps are trimmed, we're not able to generate these breadcrumbs... so we don't have 100% functional equivalence for the SDK when MAUI apps are trimmed.

See:

• public EventArgs with internal properties dotnet/maui#25563 (comment)

Sentry.Maui trim analyser issues

There is currently a bug in System.Text.Json that prevents us from publishing AOT applications to iOS:

• [release/9.0-staging] Replace a few SuppressMessage annotations with UnconditionalSuppressMessage dotnet/runtime#109186

So we can't check for AOT warnings on iOS (only trim analyser warnings for the time being).

Packages incompatible with trimming

At this time, the following packages are not compatible with trimming:

sentry-dotnet/test/Sentry.TrimTest/Sentry.TrimTest.csproj

Lines 41 to 46 in fce29a9

	<!-- The following packages are deliberately excluded from the TrimTest app because they do not support trimming -->
	<!-- Sentry.AspNetCore.Blazor.WebAssembly: produces trim warnings... not yet sure how to resolve these -->
	<!-- Sentry.Azure.Functions.Worker: `Microsoft.Azure.Functions.Worker` produces [trim warnings](https://github.com/Azure/azure-functions-dotnet-worker/issues/2899) -->
	<!-- Sentry.Hangfire: Hangfire.Core produces trim warnings and relies on Newtonsoft.Json -->
	<!-- Sentry.Log4Net: Legacy - produces trim warnings -->
	<!-- Sentry.Profiling: FastSerialization and DynamicTraceEventParser produce trim warnings -->

Of those, Sentry.Profiling and Sentry.AspNetCore.Blazor.WebAssembly are currently the only two that we might be able to address... We should create separate issues for these if we want to trimming compatibility for them.

[jamescrosswell]

Sentry.Profiling

There are a few trim warnings for Sentry.Profiling that are no trivial to resolve:

/src/FastSerialization/FastSerialization.cs(2017,21): Trim analysis error IL2072: FastSerialization.Deserializer.<>c__DisplayClass68_0.<GetFactory>b__0(): 'type' argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in call to 'System.Activator.CreateInstance(Type)'. The return value of method 'System.Func<T,TResult>.Invoke(Func<T,TResult>.T)' does not have matching annotations. The source value must declare at least the same requirements as those declared on the target location it is assigned to.
/src/FastSerialization/FastSerialization.cs(1995,17): Trim analysis error IL2057: FastSerialization.Deserializer.GetFactory(String): Unrecognized value passed to the parameter 'typeName' of method 'System.Type.GetType(String)'. It's not possible to guarantee the availability of the target type.
/src/TraceEvent/DynamicTraceEventParser.cs(957,17): Trim analysis error IL2067: Microsoft.Diagnostics.Tracing.Parsers.DynamicTraceEventData.GetDefaultValueByType(Type): 'type' argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in call to 'System.Activator.CreateInstance(Type)'. The parameter 'type' of method 'Microsoft.Diagnostics.Tracing.Parsers.DynamicTraceEventData.GetDefaultValueByType(Type)' does not have matching annotations. The source value must declare at least the same requirements as those declared on the target location it is assigned to.
/src/TraceEvent/DynamicTraceEventParser.cs(1674,21): Trim analysis error IL2057: Microsoft.Diagnostics.Tracing.Parsers.DynamicTraceEventData.PayloadFetch.FromStream(Deserializer): Unrecognized value passed to the parameter 'typeName' of method 'System.Type.GetType(String)'. It's not possible to guarantee the availability of the target type.

The warning on line 1995 of FastSerialization.cs relates to this:

type = Type.GetType(fullName);

and the related error on line 2017 relates to this code:

return (IFastSerializable)Activator.CreateInstance(type);

The code essentially seems to be trying to construct arbitrary types... which will definitely mess with trimming.

The conventional solution to this would be to use System.Text.Json and provide a custom JsonSerializerContext... so basically it would be to use different serializers (that are trim compatible).

@vaind I think you're the resident expert on all things profiling. Do you have any context for why the profiling module uses FastSerialization instead of System.Text.Json? Could we potentially swap the serialization out and replace this with System.Text.Json or, alternatively, is there maybe updated code for FastSerialization that is trim compatible?

[jamescrosswell]

Sentry.AspNetCore.Blazor.WebAssembly

Trying to include Sentry.AspNetCore.Blazor.WebAssembly in the TrimTest app results in a couple of trim warnings but nothing specific (no line numbers of specific piece of code that we could call the culprit)... so it's not really actionable. Might need to do a bit of digging to see if Trimming/AOT is possible with WASM:

    ILLink : Trim analysis error IL2111: Microsoft.JSInterop.Infrastructure.DotNetDispatcher.GetCachedMethodInfo(IDotNetObjectReference, String): Method 'Microsoft.JSInterop.Infrastructure.DotNetDispatcher.<GetCachedMethodInfo>g__ScanTypeForCallableMethods|16_0(Type)' with parameters or return value with `DynamicallyAccessedMembersAttribute` is accessed via reflection. Trimmer can't guarantee availability of the requirements of the method.
    ILLink : Trim analysis error IL2065: Microsoft.JSInterop.Infrastructure.DotNetDispatcher.ScanAssemblyForCallableMethods(DotNetDispatcher.AssemblyKey): Value passed to implicit 'this' parameter of method 'System.Type.GetMethods(BindingFlags)' can not be statically determined and may not meet 'DynamicallyAccessedMembersAttribute' requirements.

[vaind]

@vaind I think you're the resident expert on all things profiling. Do you have any context for why the profiling module uses FastSerialization instead of System.Text.Json? Could we potentially swap the serialization out and replace this with System.Text.Json or, alternatively, is there maybe updated code for FastSerialization that is trim compatible?

These all belong to perfview, we just import some of the projects from there. Not sure how we could proceed here, yet. Do we have any other 3rd party code included that has these warnings?

[jamescrosswell]

These all belong to perfview, we just import some of the projects from there. Not sure how we could proceed here, yet. Do we have any other 3rd party code included that has these warnings?

Not code no. Hangfire.Core (which is a dependency of Sentry.Hangfire) uses Newtonsoft.Json... In practice, this means the current version of Hangfire can't be used in AOT Compiled applications (theoretically it could, but only with trimming disabled - which would make the resulting binaries absolutely massive).

The only other code that we've used that had these trim warnings was our own code, which we updated for the 4.0.0 release to use the System.Text.Json source generators instead of reflection for serialisation. That's the reason I asked if it might be possible to swap FastSerialization for System.Text.Json... Creating source generated serialisers is non-trivial so there would have to be a very compelling reason to re-do all of that work for FastSerialization when it's already been done for System.Text.Json.

[bruno-garcia]

can this be latest or we need to pin?

[jamescrosswell]

We pin to get the correct version of Xcode. As of about a month ago, the GitHub macos runners are associated with specific major versions of Xcode.

• macos-14 has Xcode 15.x installed
• macos-15 has Xcode 16.x installed

I've basically started trying to pin everything (specific runner version, .NET workload versions via the ios18.0 or android35.0 monkiers etc.) since it gets us closer to deterministic builds. If we don't do this, too much changes arbitrarily between different runs against the same commit and CI fails arbitrarily.

[bruno-garcia]

do we need to set the specific android version here? I imagine it might go out of sync when we bump .NET for example

[jamescrosswell]

What we're passing here is the target framework net8.0-android34.0. That has to match one of the target frameworks in the csproj file and we pin android34.0 as the oldest possible set of APIs that can be used with net8.0 (for net9.0 it's net9.0-android35.0).

The main reason we're doing this is to ensure the android34.0 SDK gets installed as this is missing from the new GitHub runners. If we remove this, the build fails later on in the workflow.

[bruno-garcia]

we use Android 35 here and 34 above. Is that by default? We could set this as vars at the top of the workflow at least?

[jamescrosswell]

34.0 is used abote with the t:InstallAndroidDependencies parameter to install some missing dependencies. For the trim tests, I've used net9.0 as there are some new analysers in net9.0 (i.e. it picks up more issues).

So yeah, unfortunately we want to use two separate target frameworks for the two different build steps.