Repository navigation
Conversation
Align setup examples and supported platforms with SDK 6.12.1. Clarify logging initialization, use the OTLP exporter for Blazor tracing, and verify each telemetry type. Refs #19990
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
ric-oliv
left a comment
There was a problem hiding this comment.
Thank you, @sfanahata!
It looks great in general, I'm just adding a few comments.
The changes that matter most for readers are removing native tracing from the Android and Apple quick starts, the VB snippets that still don't compile, and the Blazor WASM sample rate.
Many lines in these examples set options to their default values (for example options.Native.AnrEnabled = true on Android). Either way works from the SDK side: keeping them shows readers which options exist, and removing them makes the snippets shorter. If you'd rather remove them, let me know and I'll mark the lines.
| // Set to 1.0 to capture 100% of spans for tracing. | ||
| // We recommend reducing this value in production. | ||
| options.TracesSampleRate = 1.0; | ||
| options.Native.EnableTracing = true; |
There was a problem hiding this comment.
I'd remove this line. This snippet is the general quick-start setup, and Native.EnableTracing is an opt-in we deliberately keep off by default. It makes the embedded Android SDK create its own transactions in addition to the .NET ones, which duplicates instrumentation and adds transaction volume (see getsentry/sentry-dotnet#4032).
| options.Native.EnableTracing = true; |
| The snippet also turns on: | ||
|
|
||
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> | ||
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> and `Native.EnableTracing` for the embedded Android SDK |
There was a problem hiding this comment.
Goes with removing options.Native.EnableTracing from the snippet:
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> and `Native.EnableTracing` for the embedded Android SDK | |
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> |
Also, line 35 lists automatic Activity lifecycle and User Interaction tracing among the features you get by default. Those come from the Android SDK's own tracing, so they need the same opt-in. Please change line 35 to:
- Opt-in automatic [Activity lifecycle tracing](/platforms/android/tracing/instrumentation/automatic-instrumentation/#activity-instrumentation) and [User Interaction tracing](/platforms/android/tracing/instrumentation/automatic-instrumentation/#user-interaction-instrumentation) through the embedded Android SDK. See <PlatformLink to="/configuration/native-options/#Native.EnableTracing">`Native.EnableTracing`</PlatformLink>.| // Set to 1.0 to capture 100% of spans for tracing. | ||
| // We recommend reducing this value in production. | ||
| options.TracesSampleRate = 1.0; | ||
| options.Native.EnableTracing = true; |
There was a problem hiding this comment.
Same thing, I'd also remove it here.
| options.Native.EnableTracing = true; |
| The snippet also turns on: | ||
|
|
||
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> | ||
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> and `Native.EnableTracing` for the embedded Cocoa SDK |
There was a problem hiding this comment.
Goes with removing options.Native.EnableTracing from the snippet:
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> and `Native.EnableTracing` for the embedded Cocoa SDK | |
| - Tracing: via <PlatformLink to="/configuration/options/#TracesSampleRate">`TracesSampleRate`</PlatformLink> |
| - Native crash reporting, including: | ||
| - Automatically [attach screenshots to Native exceptions](/platforms/apple/guides/ios/configuration/options/#attachScreenshot) | ||
| - Detect [App Hangs](/platforms/apple/configuration/app-hangs/) | ||
| - [Automatic performance tracing](/platforms/apple/tracing/) |
There was a problem hiding this comment.
Automatic performance tracing comes from the Cocoa SDK's own tracing, which is off unless you opt in. Please say so here:
| - [Automatic performance tracing](/platforms/apple/tracing/) | |
| - Opt-in [automatic performance tracing](/platforms/apple/tracing/). See <PlatformLink to="/configuration/native-options/#Native.EnableTracing">`Native.EnableTracing`</PlatformLink>. |
| <Alert level="warning" title="Note"> | ||
|
|
||
| The SDK needs to be initialized only once. If a `DSN` is made available to this integration, by default it **will** initialize the SDK. If you do not wish to initialize the SDK via this integration, set the `InitializeSdk` flag to **false**. Not providing a DSN or leaving it as `null` instructs the integration not to initialize the SDK and unless another integration initializes it or you call `SentrySdk.Init`, the SDK will stay disabled. | ||
| Initialize the SDK once. `InitializeSdk` defaults to `true`, and initialization can resolve a DSN from `SENTRY_DSN` even when you omit `Dsn`. If another integration or `SentrySdk.Init` owns initialization, set `InitializeSdk = false`. Omitting the DSN doesn't prevent reinitialization and can replace the existing SDK configuration. |
There was a problem hiding this comment.
Please use this wording. If SENTRY_DSN isn't set either, initialization fails because no DSN was found, so nothing gets replaced.
| Initialize the SDK once. `InitializeSdk` defaults to `true`, and initialization can resolve a DSN from `SENTRY_DSN` even when you omit `Dsn`. If another integration or `SentrySdk.Init` owns initialization, set `InitializeSdk = false`. Omitting the DSN doesn't prevent reinitialization and can replace the existing SDK configuration. | |
| Initialize the SDK once. `InitializeSdk` defaults to `true`, and initialization can resolve a DSN from `SENTRY_DSN` even when you omit `Dsn`. If another integration or `SentrySdk.Init` owns initialization, set `InitializeSdk = false`. Omitting the DSN doesn't prevent reinitialization: the target either uses `SENTRY_DSN` and replaces the existing SDK configuration, or fails to initialize because no DSN was found. |
| <Alert> | ||
|
|
||
| The SDK only needs to be initialized once. If a `DSN` is made available to this integration, by default it **will** initialize the SDK. If you do not wish to initialize the SDK via this integration, set the `InitializeSdk` flag to **false**. Not providing a DSN or leaving it as `null` instructs the integration not to initialize the SDK and unless another integration initializes it or you call `SentrySdk.Init`, the SDK will stay disabled. | ||
| Initialize the SDK once. The C# callback overload defaults `InitializeSdk` to `true` and can resolve a DSN from `SENTRY_DSN`. Set `InitializeSdk = false` when another integration or `SentrySdk.Init` owns initialization. Omitting the DSN from that callback doesn't prevent reinitialization. |
There was a problem hiding this comment.
Please use this wording. Without SENTRY_DSN, the callback overload throws because no DSN was found.
| Initialize the SDK once. The C# callback overload defaults `InitializeSdk` to `true` and can resolve a DSN from `SENTRY_DSN`. Set `InitializeSdk = false` when another integration or `SentrySdk.Init` owns initialization. Omitting the DSN from that callback doesn't prevent reinitialization. | |
| Initialize the SDK once. The C# callback overload defaults `InitializeSdk` to `true` and can resolve a DSN from `SENTRY_DSN`. Set `InitializeSdk = false` when another integration or `SentrySdk.Init` owns initialization. Omitting the DSN from that callback doesn't prevent reinitialization: it uses `SENTRY_DSN` if set and replaces the existing SDK configuration, and otherwise throws because no DSN was found. |
| The simplest way to initialize Sentry in ASP.NET Core is by using the `UseSentry` extension method from the `Sentry.AspNetCore` package in conjunction with the [framework configuration system](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/). | ||
|
|
||
| Call `UseSentry` with your DSN and the options you want. The SDK provides this as extension methods to support ASP.NET Core `2.X`, `3.X`, and `5.X` and later. | ||
| `Sentry.AspNetCore` 6.x requires .NET 8 or later. Call `UseSentry` with your DSN and the options you want. Applications on older .NET versions need a compatible older SDK version; see the <PlatformLink to="/migration/">Migration Guide</PlatformLink>. |
There was a problem hiding this comment.
Please name the version instead of pointing to the Migration Guide, which doesn't say which one to use. 4.x is the newest version that supports .NET 6 and 7.
| `Sentry.AspNetCore` 6.x requires .NET 8 or later. Call `UseSentry` with your DSN and the options you want. Applications on older .NET versions need a compatible older SDK version; see the <PlatformLink to="/migration/">Migration Guide</PlatformLink>. | |
| `Sentry.AspNetCore` 6.x requires .NET 8 or later. Call `UseSentry` with your DSN and the options you want. For .NET 6 or 7, use `Sentry.AspNetCore` 4.x. |
|
|
||
| ```csharp | ||
| // Add these to your existing using statements. | ||
| using System.Security; |
There was a problem hiding this comment.
Please add using Sentry; here, as this PR does in the other guides. Without it, the snippet compiles only when implicit usings are turned on. Please also add using Sentry; above using Sentry.Protocol; in the first snippet (line 36).
| using System.Security; | |
| using System.Security; | |
| using Sentry; |
| { | ||
| _sentrySdk.Dispose(); | ||
| base.Dispose(); | ||
| _sentrySdk?.Dispose(); |
There was a problem hiding this comment.
Moving this to Application_End is the right fix. Please also make the field static:
- here, change line 67 to
private static IDisposable _sentrySdk; - in the ASP.NET guide (
docs/platforms/dotnet/guides/aspnet/index.mdx, line 48), changeprivate IDisposable _sentry;toprivate static IDisposable _sentry;
ASP.NET can run Application_Start and Application_End on different HttpApplication instances. With an instance field, this call can do nothing and skip the flush on shutdown.
|
The plan checks page loads on the changed guides, 404s on that path, and MDX runtime warnings. Services: Mention PlanWhat changedReaders of the .NET getting-started pages now see corrected setup and verification steps. The changed routes are:
RiskA broken MDX include can hide the new verification text. Intended effectThe new wording is not queryable from telemetry. Regression watchIf this change is wrong, the changed guides fail to render or return 404. For page loads use The page-load band comes from 90 loads in the prior 24h and 122 loads in the last 24h.
Not observableWording correctness of the new C# and VB snippets. Get Slack DMs about this change: cursor.com/automations/rollouts |
Follow-up to #19990: correct setup and verification across the base .NET quick start and all 19 integration guides, checked against SDK 6.12.1.
Most setup inaccuracies predate the template migration. This also corrects the new claim that
Sentry.Profilinginstalls on .NET Framework and adds the tracing option missing from the WinForms VB examples.Validation: 31 focused documentation tests and all applicable pre-commit checks passed, including typo, external-link, and trailing-slash checks. All 22 changed MDX files compiled through the repository pipeline with website telemetry disabled in the temporary validation harness; shared includes, JSON examples, and the new OTLP link resolved. The .NET SDK is unavailable locally, so C#/VB snippets were source-checked but not compiled or run.
IS YOUR CHANGE URGENT?