-
-
Notifications
You must be signed in to change notification settings - Fork 220
Support Native AOT on .NET 7+ #2247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
None of those actually explain the missing stack trace when using
Indeed,
Not sure why they give the same offset in both hex and decimal, and the rest of the string is useless. But it is indeed there. Getting the rest of the info we need (module, assembly, etc.) may be difficult. |
Seems Native AOT will run also on iOS: dotnet/runtime#80905 |
Uh oh!
There was an error while loading. Please reload this page.
Problem Statement
.NET 7 introduced "Native AOT" deployments for Windows and Linux and .NET 8 adds Native AOT support for macOS.
Initial investigation
Testing on Windows, a .NET console app with Sentry publishing with Native AOT gives these warnings:
Trying to capture an exception shows internal serialization failures related AOT trimming:
The error event does come through to Sentry, but without its stack trace.
Trimming was added in .NET 6 as an option for self-contained deployments, but is required when Native AOT is used. There is guidance for libraries here:
https://learn.microsoft.com/dotnet/core/deploying/trimming/prepare-libraries-for-trimming
Checking for trimming errors by adding
<IsTrimmable>true</IsTrimmable>
toSentry.csproj
shows three main areas where there are trimming issues in the Sentry SDK:Ben.Demystifier
uses reflection heavily. We already learned (in Fix: Disable Ben.Demystifier for UWP by default. #821) that we can't use it by default in UWP because .NET Native also doesn't like it. We'll have to do something similar for Native AOT. That means noStackTraceMode.Enhanced
for Native AOT. 😞 (unless we can find an alternative)Our
WinUIUnhandledExceptionIntegration
uses reflection to attach toMicrosoft.UI.Xaml.Application.Current.UnhandledException
. This is primarily for .NET MAUI on Windows, but is also for non-MAUI WinUI 3 applications.Our
JsonExtensions.WriteDynamicValue
method has a long list of types it will serialize, but then ultimately just tries to serializeobject
. Such usage is invalid in STJ when Native AOT is used.Solution Brainstorm
We should be able to disable
Ben.Demystifier
and just useStackTraceMode.Original
, but we'll need to add various trimmer attributes to the code to prevent the trimming warnings from breaking the build. This will be tricky, as we importBen.Demystifier
as a submodule.We can either move
WinUIUnhandledExceptionIntegration
back to theSentry.Maui
package, or to a new package, or we can make a Windows target for the mainSentry
package to avoid reflection. Alternatively, we could explore ifDynamicDependencyAttribute
would let us keep it as-is without it being trimmed out.The main pain point is going to be JSON serialization. We have lots of places where we serialize
object
types - some of which are strictly internal, but others are exposed to end users. We could consider an API that would let the end-user provideJsonSerializerContext
. See https://devblogs.microsoft.com/dotnet/try-the-new-system-text-json-source-generator/Here are all the public APIs that would be affected by such a change:
All of these currently flow through to serialization via
JsonExtensions.WriteDynamicValue
.After we ensure Sentry works without compile errors/warnings, we should also see what might need to change to support symbolication for .NET Native AOT apps.
The text was updated successfully, but these errors were encountered: