Closed PeterDraex closed 2 months ago
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.
Can we get some support docs for Blazer Server Side?
@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.
I played a bit during hackweek. Some learnings/ideas:
UseSentry
on the WebAssemblyHostBuilder
. (JS SDK needs to be added by itself)Sentry.Extensions.Logging
to capture errors/breadcrumbs
ILogger
have the whole stack trace in the message. so TODO is to parse those out of the messages. User-Agent
to get browser/OS info in Sentry: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).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.dotnet.wasm
to add debug_id
worked to some degree. On my tests only in release/published apps. Ideally dotnet adds this OOTB
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:
Sentry.Profiling
. At least from .NET 8 if I read some threads online, EventPipe should get some data. Not sure about prod buildsconsole.time
and console.timeEnd
(see this)).NET 8 introduces WasmStripILAfterAOT
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#?).
How to emit source maps:
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.
As a very soft ETA, we would like to be able to support this sometime within the next quarter.
The new package Sentry.AspNetCore.Blazor.WebAssembly
has only a target for .NET 6 and is missing .NET 8 as a target.
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.
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.
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.
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.
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?
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.
Therefore a multi target is probably not needed.
Awesome, thanks @klemmchr - that's a relief!
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
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