Trimming for .NET 7+

[jamescrosswell]

Summary

One of the pre-requisites for supporting AOT for Sentry to support trimming.

In the Sentry.csproj core package, there are 3 primary challenges with this:

1. BenDemystifier
2. WinUIUnhandledExceptionIntegration
3. System.Text.Json.JsonSerializer

Ben.Demystifier ✅

Ben.Demystifier uses reflection heavily to provide enhanced stack traces.

Approach / Solution

When setting <IsAotCompatible>true</IsAotCompatible> in Sentry.csproj, we get a bunch of errors/warnings about Ben.Demystifier not being compatible with trimming.

To solve this, in our fork of Ben.Demystifier we surface those via RequiresUnreferencedCode attributes on the relavant classes. That way Ben.Demystifier itself compiles when included in a solution with IsAotCompatible set, but only if any code leveraging it handles the warnings (either be not using the Ben.Demystifier functionality in question or by supressing the warnings).

• Added RequiresUnreferencedCode on non-trimmable code Ben.Demystifier#1 includes the necessary changes to Ben.Demystifier
• Then we set UnconditionalSuppressMessage on:
  • DebugStackTrace.CreateFrames and
  • DebugStackTrace.TryCreateManagedFrame and
  • DebugStackTrace.TryCreateManagedFrame and

WinUIUnhandledExceptionIntegration ✅

WinUIUnhandledExceptionIntegration uses reflection to set Microsoft.UI.Xaml.Application.Current.UnhandledException to Sentry's WinUIUnhandledExceptionHandler for customers using Microsoft.UI.Xaml (.NET MAUI targeting Windows or WinUI 3 applications). The relection code it users generates the following errors with IsTrimming==true:

Approach / Solution

• For the time being, if IsTrimmable == true we're not registering our WinUiUnhandledExceptionHandler automatically and we'll need to provide some guidance to users who are both targeting WinUI and wanting to enable AOT compilation.

System.Text.Json.JsonSerializer ✅

When using Trimming, serialization can't be performed using old reflection based technique (which utilise JsonSerializer overloads accepting JsonSerializerOptions parameters).

Approach / Solution

Instead we need to use source generated serializers that can be supplied to overloads JsonSerializer overloads accepting JsonSerializerContext arguments. See System.Text.Json source generators for details.

Bumping the .netcoreapp3 version

In order to use the new source generated JSON serializers, we had to add a PackageReference to System.Text.Json" Version="6.0.8" for version of .NET prior to .net6.0. That resulted in a new error: System.Runtime.CompilerServices.Unsafe doesn't support netcoreapp3.0. Consider updating your TargetFramework to netcoreapp3.1 or later.... As a results, we've had to bump the target framework in our Sentry packages from netcoreapp3.0 to netcoreapp3.1.

Next Steps

Beyond Sentry.csproj many of the other projects can just be added as is to SentryAot.slnf and they compile and tests run without problem. Some have challenges however. One that was obvious during initial exploration is the use of ConfigureFromConfigurationOptions<TOptions> classes to initialize a number of the integrations... which doesn't work with Trimming enabled. This affects:
- Sentry.Extensions.Logging
- Sentry.Maui
- Sentry.Azure.Functions.Worker
- Sentry.AspNetCore

I think we should deal with that in a separate pull request though.

Additional Reference material:

• The minimal API AOT compilation template
• Intro to Trim warnings
• Intro to AOT warnings
• Creating a SourceGenerator
• System.Text.Json source generators
• Packaging Generators in Libraries
• The new configuration binder source generator

[vaind]

Some minor comments/change suggestions.

I'd still prefer the new solution to be removed (at least until we need it, which we don't in this PR) but that's just me.

I think someone else should review this PR too. @bruno-garcia @bitsandfoxes

[vaind]

LGTM with minor comments/ideas for improvement

[vaind]

Maybe the regexp could do without the negative lookahead

Suggested change

	<PropertyGroup Condition="'$(TargetFramework)' != 'net7.0-android' AND $([System.Text.RegularExpressions.Regex]::IsMatch('$(TargetFramework)', '^(?!net5\.|net4\d{2}|netcoreapp|netstandard)net\d+'))">
	<PropertyGroup Condition="'$(TargetFramework)' != 'net7.0-android' AND $([System.Text.RegularExpressions.Regex]::IsMatch('$(TargetFramework)', '^net[6-9]'))">

[vaind]

Oh wait, we also need changelog entries for these breaking changes, right?

[jamescrosswell]

Oh wait, we also need changelog entries for these breaking changes, right?

Yeah we do... it's a bit tricky off the basis of this PR only. I suspect we might want to mention something about the symbolication and debug stack traces, and that might require details from some of the PRs you've been working on @vaind.

I've put something basic in there for now. It will need to be adapted once #2778 has been done and we might want to adapt it further and add references to other PRs relevant to AOT.