Provide way to manually instrument WinUIUnhandledExceptionHandler

[jamescrosswell]

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

Lines 104 to 105 in 79b1dc3

	// TODO: We need to create a mechanism for users to wire this up manually and document this in a separate PR
	_options.LogError(ex, "Could not attach WinUIUnhandledExceptionHandler.");

• Code changes
• Docs

Code changes

From here, Sentry 3.x has the reflection equivalient of:

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

  Line 81 in 343d921

  // Microsoft.UI.Xaml.Application.Current.UnhandledException += WinUIUnhandledExceptionHandler;

The exception handler it wires up is currently private though. To make this easier for users, we need to expose some way for them to be able to wire this up via our public API.

Docs

Once the code changes have been made, we should update the docs to show how people can manually wire up the exception handler that we provide.

Cross reference docs with this comment.

[jamescrosswell]

Although it's possible to create an API to let SDK users manually attach Sentry's unhandled exception handler for WinUI 3 applications, there are a couple of red flags in the code that make me think we don't want to do this, The main one is this:

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

Lines 116 to 117 in cf26d46

	[UnconditionalSuppressMessage("TrimAnalyzer", "IL2075", Justification = AotHelper.SuppressionJustification)]
	private void WinUIUnhandledExceptionHandler(object sender, object e)

Because we don't take a dependency on the WinUI3 packages we don't have access to some of the critical types like Microsoft.UI.Xaml.UnhandledExceptionEventArgs... which means that, even in our event handler, we're using reflection to read out the properties of the eventArgs.

Without using reflection then, I think we keep coming back to the same conclusion (that we would need to add a Sentry.WinUI3 package or something to properly support WinUI 3 applications without people having to wire up the event handler by copying/pasting code from our documentation).

Building a Sentry.WinUI3 package would be challenging however. For one thing, currently we build and publish all of our NuGet packages from our macOS runner on GitHub... I don't know how we could do that for a package with WinUI3 dependencies, so the process that we use for release builds would start to get very complicated and more fragile.

cc: @bitsandfoxes

[bruno-garcia]

Building a Sentry.WinUI3 package

Wouldn't it be Sentry.UI.Xaml? As it would depend on Microsoft.UI.Xaml

challenging however. For one thing, currently we build and publish all of our NuGet packages from our macOS runner on GitHub.

It seems like it carries a bunch of native libs but for building/packaging purposes I imagine it would build on Mac if we left it at netstandard2.X, no? That package has uap10.0 so we might need to add that and I dunno if it would compile on a Mac.

If we had to build it on windows (for packaging purposes, I understand we need for running tests), we would need to do what we did on Unity. Where CI builds on the platforms that are needed. Then assembles the package once all builds are ready and artifacts available.
It would definitely be time consuming to set that up though.

That said, given the fact AppCenter is getting decommissioned could be nice to have a decent support here so folks migrate over. But I do understand this might involve a lot of effort on our end and we need to consider that carefully.

Another benefit of a package is that install instructions can be simpler. We can add a hook/extension method to their app host (if there's one). And we can track the downloads on nugettrends.com.