Sentry support for Blazor WebAssembly

[PeterDraex]

Problem Statement

This is a feature request for support for Blazor WebAssembly. According to #317, there seems to be at least some level of integration supported, but I couldn't find any installation tutorial. I would love to see support including features like User Feedback Prompt or Tunneling.

Solution Brainstorm

No response

[bruno-garcia]

We have a sample in the repo: https://github.com/getsentry/sentry-dotnet/tree/23be90cd6b57446f7bbfeecc7c5f30eb692999fc/samples/Sentry.Samples.AspNetCore.Blazor.Wasm

But indeed no docs at the time. That said, support is there, it's just .NET running on Wasm (MonoAOT afaik).

User Feedback would require you to call the C# API. If you're using the JS widget, you'd need to do JS interop to pass around the event id. But it should work too.

[krossley]

Can we get some support docs for Blazer Server Side?

[mattjohnsonpint]

@krossley - I opened a new issue specifically for Blazor Server here: #2329

We don't have any specific guidance at the moment. As always, we're open to PRs. Thanks.

[bruno-garcia]

I played a bit during hackweek. Some learnings/ideas:

• [Hackweek] Blazor Wasm SDK #2569

Stuff I explored in the draft PR above

• JavaScript SDK bundled in Sentry.AspNetCore.Blazor
  • Docs would recommend adding the script tag directly, before loading the blazor.wasm.js file. This way Sentry can capture errors loading the .NET runtime. Performance and even Profiling will include time spent on that. And Replay will start recording as early as possible. I explored starting the JS SDK from C#, using the properties in C# to pass values to JS and it was all doable. But we'd be missing out too much.
• Session Replay works pretty well
• Browser performance monitoring. Didn't get C# span data into the JS layer though.
• Download JavaScript SDK during .NET package build
  • Didn't set upload sourcemap tasks though
• Init the .NET SDK with UseSentry on the WebAssemblyHostBuilder. (JS SDK needs to be added by itself)
• Support for dependency injection in Blazor wasm
• Auto registering Sentry.Extensions.Logging to capture errors/breadcrumbs
  • Some exceptions logged via ILogger have the whole stack trace in the message. so TODO is to parse those out of the messages.
• Scope changes in C# propagate to JavaScript
• Set User-Agent to get browser/OS info in Sentry:
• Navigation breadcrumbs (from page A to B)
• Since we include a Crash method in the SDK, the package includes a component with sample errors. Things to consider are: JS calling into C# and vice-versa. Which SDK captures the data? How scope data flows (my experiment has C#->JS since main lang is C# on Blazor).

WebAssembly error monitoring

• Microsoft has great docs, covering different areas where things can go wrong
• The Blazor package could possibly be renamed to WebAssembly. It doesn't have any dependency Blazor per-se. Could be used by Avalonia and Uno Wasm too. Avalonia has .Browser and .Browser.Blazor packages.
• Patching dotnet.wasm to add debug_id worked to some degree. On my tests only in release/published apps. Ideally dotnet adds this OOTB
  • Blazor - WebAssembly build_id section dotnet/runtime#91049
  • @sentry/wasm will not work if wasm url is a blob url sentry-javascript#8259 (comment)
    • In some tests I hit this issue. So with @mitsuhiko's help we added a hack to get a URL by throwing from the module and parsing the stack trace
  • Patching it caused an integrity check to fail. Internet said false turns it off. That resolved it

Blazor Server

Lots to explore here. Since we have decent support with the Sentry.AspNetCore package already, I didn't invest too much time. But some areas:

• Circuit error handling: The SignalR circuit can fail if the component rendering breaks (according to t
• That's tracked here: Support Blazor Server #2329

Performance monitoring

• Performance coming from the JS SDK seems quite rich already. But having insights of what's happning in blazor and on the code the user writes is missing. We could use the JS Interop to call into JS SDK to start/end span for example for blazor component lifecycle stuff (at least the built-in one). Or have a span observers similar to what we have on Scope to pass data from C# to JS.
• We could monkeypatch some framework functions to get auto span for wasm bridge (as proposed by @AbhiPrasad)

Profiling

• We might be able to leverage Sentry.Profiling. At least from .NET 8 if I read some threads online, EventPipe should get some data. Not sure about prod builds
• Browser profiling is likely a good candidate. We can use the JS interop to add some blocks from C# (console.time and console.timeEnd (see this))

[bruno-garcia]

https://twitter.com/davidfowl/status/1701667585522290730

[bruno-garcia]

.NET 8 introduces WasmStripILAfterAOT

[jamescrosswell]

https://twitter.com/davidfowl/status/1701667585522290730

Weird that they separate out .NET and C#... I wonder what the results would look like if those two were grouped together (who is using C# but not .NET??? How could less people be using .NET and C#?).

[bruno-garcia]

How to emit source maps:

• Error hard to debug because of minified JS dotnet/aspnetcore#54555 (comment)

[klemmchr]

Is there any timeline on a proper Blazor SDK? The current situation is not really satisfying since Sentry in Blazor WASM using the existing SDKs misses out on all the cool features like replays and profiling.

[bitsandfoxes]

As a very soft ETA, we would like to be able to support this sometime within the next quarter.

[klemmchr]

The new package Sentry.AspNetCore.Blazor.WebAssembly has only a target for .NET 6 and is missing .NET 8 as a target.

[jamescrosswell]

The new package Sentry.AspNetCore.Blazor.WebAssembly has only a target for .NET 6 and is missing .NET 8 as a target.

Does it need to target net8.0?

We normally target the minimum possible version necessary. When we do have multiple targets it's usually because there is some additional functionality that is only available (via conditional compilation directives) in one or more of the targets.

[klemmchr]

It is not explicitly needed, but Microsoft recommends to consider multi-targeting with the same codebase when having a package or library dependency.

✔️ CONSIDER multi-targeting even if your source code is the same for all targets, when your project has any library or package dependencies.

Your project's dependent packages, either direct or downstream, might use the same code APIs while wrapped inside different versions of the dependent assembly per target framework. Adding specific targets ensures that your consumers do not need to add or update their assembly binding redirects.

https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting#multi-targeting

[bitsandfoxes]

Fair enough. While true, it would greatly increase everything, from package size to time spent on building and testing in CI.
Maybe @bruno-garcia can chime in with some historic context.

[klemmchr]

I don't know your CI setup in depth, but would including a multi target into this (quite empty) library really increase your build time by a noticable amount? This might be true if you have to rebuild all dependencies as well but this is not the case when looking at your workflows.
Same goes for package size, this library is quite small and will not grow particularly strongly in the future.

[jamescrosswell]

I think if we adopt the policy of targeting everything for Sentry.AspNetCore.Blazor.WebAssembly we'd want to be consistent and do that for all the other packages as well... which means we'd have quite a few extra binaries and debug files for every NuGet package.

When building locally we automatically upload source and debug for every build (so that things like source link etc. work)... the uploading of that information extends the build time for those local builds quite considerably so if we were uploading another 30% of data it would be a pain.

We could do it, but only if there was some obvious/compelling benefit... so a good understanding of why Microsoft make that recommendation and how following that recommendation would benefit our SDK customers.

@klemmchr was there some specific reason you wanted/needed this?

[klemmchr]

After digging deeper into this topic it seems that this recommendation is a remnant from .NET Framework times where binding redirects were a thing. Therefore a multi target is probably not needed.

[jamescrosswell]

Therefore a multi target is probably not needed.

Awesome, thanks @klemmchr - that's a relief!

[bruno-garcia]

We should add net8.0 too, specially when u take dependencies that have net8.0 builds as u want the end user to resolve the net8.0 dep chain