Sentry assembly produces trim warnings when compiling AOT

[jamescrosswell]

Steps to reproduce

1. Follow the Tutorial to Publish an ASP.NET Core app using Native AOT
2. Add the Sentry.AspNetcore NuGet package to the applications
3. Configure Sentry per the docs

Now publish the application again.

Expected Result

Application should publish without warnings.

Actual Result

The application is published correctly but the publish operation generates trim warnings:

MyFirstAotWebApi -> /Users/jamescrosswell/code/MyFirstAotWebApi/bin/Release/net8.0/osx-arm64/publish/
jamescrosswell@MacBook-Pro MyFirstAotWebApi % dotnet publish -f net8.0
MSBuild version 17.9.6+a4ecab324 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
MyFirstAotWebApi -> /Users/jamescrosswell/code/MyFirstAotWebApi/bin/Release/net8.0/osx-arm64/MyFirstAotWebApi.dll
Generating native code
/Users/jamescrosswell/.nuget/packages/sentry/4.4.0/lib/net8.0/Sentry.dll : warning IL2104: Assembly 'Sentry' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries [/Users/jamescrosswell/code/MyFirstAotWebApi/MyFirstAotWebApi.csproj]
MyFirstAotWebApi -> /Users/jamescrosswell/code/MyFirstAotWebApi/bin/Release/net8.0/osx-arm64/publish/

Remarks

This is very odd as we explicitly set the IsAotCompatible MS Build property which should set IsTrimmable and enable the trim analyzer as well:

sentry-dotnet/src/Sentry/Sentry.csproj

Lines 27 to 29 in 4b33c36

	<PropertyGroup Condition="'$(FrameworkSupportsAot)' == 'true'">
	<IsAotCompatible>true</IsAotCompatible>
	</PropertyGroup>

If there are any trim warnings then, we should be getting these when building Sentry for the net8.0 targets.

[bitsandfoxes]

This happened sporadically and was not 100% reproducible?

[tipa]

This happens when using NativeAOT in an iOS or macOS app while dotnet publish. I can provide an example project if it helps

[bitsandfoxes]

An example would be super appreciated!

[tipa]

Here's the example project: test_macos.zip
As I said, to reproduce just dotnet publish

[jamescrosswell]

Thanks @tipa,

We can reliably reproduce this by enabling trimming on the Sentry.Samples.Console.Basic project per the docs.

There are two problems.

MiscExtensions

The MiscExtensions.GetProperty, MiscExtensions.GetStringProperty and MiscExtensions.GetGuidProperty methods, which are only used by the DiagnosticSource integration, rely on reflection to read properties from arbitrary objects. The heart of the integration is SentrySqlListener : IObserver<KeyValuePair<string, object?>>, which gets notified of DB operations via random object arguments that are typically anonymous classes... so the only way to inspect these is via reflection (there's no way to cast them to concrete types).

We could:

1. Move those extension methods into some kind of ReflectionHelper class in the Sentry.Internal.DiagnosticSource namespace
2. Disable the integration if Trimming is enabled
3. Suppress the IL2075 warning as we know none of that code will ever get executed when trimming is enabled (since we disable the integration in that case)

WinUIUnhandledExceptionIntegration

For this one, the issue is here:

sentry-dotnet/src/Sentry/Integrations/WinUIUnhandledExceptionIntegration.cs

Lines 112 to 113 in 83d8b4e

	handled = (bool)eventArgsType.GetProperty("Handled")!.GetValue(e)!;
	exception = (Exception)eventArgsType.GetProperty("Exception")!.GetValue(e)!;

Here I think we've used reflection to avoid creating a dependency on WinUI stuff in the core Sentry nuget package. We could:

• Either move the integration to a Sentry.WinUI package... which would be another integration to maintain but WinUI is probably here to stay so maybe not a bad idea
• Or remove the integration (which is pretty minimal) and just provide a code example in the docs instructing people how they can wire up a global exception handler etc. manually