Repository navigation
docs(dotnet): Update logging docs for SDK 7.0.0 - #19925
jamescrosswell wants to merge 13 commits into
Conversation
In sentry-dotnet 7.0.0, SentryOptions.EnableLogs and EnableMetrics are removed, and the Serilog, NLog, log4net and Microsoft.Extensions.Logging integrations no longer initialize the SDK. Initialize Sentry with SentrySdk.Init or a host integration first, then add the integration. Serilog, NLog and log4net send logs without a switch; EnableLogs stays only on the ASP.NET Core, MAUI and Blazor WebAssembly options. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
UseOpenTelemetry() and TracerProviderBuilder.AddSentry() have been obsolete since 6.12.0. Use UseOtlp() and AddSentryOtlpExporter from Sentry.OpenTelemetry.Exporter, as the version7 sample does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
It happens only when Serilog, NLog or log4net is also registered as an ILogger provider, so name that case instead of "ILogger entries also go to" the framework. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
|
This change rewrites logging setup pages for a new SDK major. Readers now see Init-first examples. Three logging frameworks send logs without a flag. The plan checks page loads, client errors, and RSC fetch failures on those paths. An issue escalates when those pages stop loading or those errors rise. Services: Mention PlanWhat changed.NET logging pages now tell readers to call sentry-docs must deploy before this copy is live. The Vercel production project maps to that service. develop-docs does not ship these paths. RiskWrong copy can make readers skip Init or send each log twice. A PlatformSection mistake can show the wrong snippet on sibling logs pages. Removed NLog includes fall back to generic environment and release copy. A failed MDX render can hide Azure Functions or Blazor setup. The shared logs includes also ship to every .NET logs page. Intended effectTelemetry cannot show that the new 7.0.0 wording is live. The executor cannot mark
Regression watchThis diff can break render of the changed guides and every .NET logs page that pulls the shared includes. Watch client errors and RSC fetch failures first. Those are the symptoms users and on-call would see. Then watch not-found and page-load share so a silent blank path is not missed.
Not observableThe new 7.0.0 wording is not in telemetry. Pageload traces did not match these URL transactions, so latency is not a watch. Reader setup mistakes in downstream apps are not in this project. |
## DESCRIBE YOUR PR
Fixes two errors in the NLog docs. Both are accurate for the current 6.x
SDK, so this can merge now.
- **NLog guide options list:** `SendEventPropertiesAsData` and
`SendEventPropertiesAsTags` don't exist. The target's settings are
`IncludeEventProperties`, which NLog's `TargetWithContext` provides and
`SentryTarget` sets to `true`, and `IncludeEventPropertiesAsTags`.
`Layout` was described as "layout for the NLog logger". It's the layout
for the message of events sent to Sentry, and defaults to `${message}`.
- **NLog set-tag example:** the C# and F# tabs set `"${logger}"` on the
scope. Sentry doesn't render NLog layouts there, so the tag value was
the literal string `${logger}`. The tabs now add the tag to the target,
matching the `NLog.config` tab, and a sentence says layouts only work in
target tags.
Closes getsentry/sentry-dotnet#5716
### Notes for review
- I checked the options list against
`src/Sentry.NLog/SentryNLogOptions.cs` and `SentryTarget.cs` on
sentry-dotnet `main`. Only target tags go through `RenderLogEvent`.
Nothing in Sentry.NLog reads scope tags. A run against Sentry.NLog
6.12.0 sent `logger = MyApp.Checkout` for the target tag and
`scope_logger = ${logger}` for the scope tag.
- The list is still not exhaustive. It leaves out `BreadcrumbCategory`,
`Dsn`, `Release`, `Environment`, `EnableLogs`, `ShutdownTimeoutSeconds`
and `FlushTimeoutSeconds`. I didn't add them because 7.0.0 removes most
of them from the target.
- The new code tabs set `options.Dsn` to mirror the `dsn` attribute in
the `NLog.config` tab, since the 6.x target initializes the SDK.
- #19925, which merges at sentry-dotnet 7.0.0 GA,
edits the same two files. It removes `InitializeSdk` from the options
list and `dsn` from the set-tag target, so it will need `master` merged
in later. At that point it should also drop `options.Dsn` from the new
code tabs, because `SentryNLogOptions` no longer has it in 7.0.0.
- The C# and F# snippets compile against Sentry.NLog 6.12.0.
## IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs
to go live.
Select exactly one option. For deadlines, replace `YYYY-MM-DD` with the
due date. You can update this information later by editing the PR
description.
- [ ] Urgent deadline (GA date, etc.): YYYY-MM-DD
- [ ] Other deadline: YYYY-MM-DD
- [x] No deadline: Not urgent, can wait up to 1 week+
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@ric-oliv thanks for testing this so thoroughly. Rather than document the workaround, I've opened getsentry/sentry-dotnet#5763 to fix it in the SDK. When the NLog, Serilog or log4net integration already receives an app's Let's hold the duplicate-capture note for the NLog and log4net guides until that's decided. If it lands for 7.0, the note becomes one sentence about which side handles |
…y without duplicates Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… across host apps Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Note the External links check will continue to fail until this makes it into That will happen when we make the v7.0.0 release (we don't want to merge these docs until after then anyway). That PR also addresses the comment from @ric-oliv above. |
getsentry/sentry-dotnet#5755 closed without moving the ILogger integration out of UseSentry, so EnableLogs stays on the host options. Logging.AddSentry() can now add Sentry's logger providers back after ClearProviders(), and DecompressionMethods no longer includes Brotli. Rewrite the EnableLogs section around what turns logs on in each kind of app, update the ClearProviders and redundant AddSentry advice, and add an item for the Brotli default. Sum up the Serilog, NLog and log4net setups in the guide, so it doesn't depend on #19925 merging first. The release candidate note lists the two places where rc.2 still differs. Refs NET-860 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
sentry-dotnet 7.0.0 adds Sentry.Extensions.Hosting, whose UseSentry on IHostBuilder is how Azure Functions (isolated) apps start Sentry, also with the ASP.NET Core integration. Install that package, call UseSentry on the HostBuilder chain, and set EnableLogs to send ILogger entries as logs, as on the other host integrations. Remove SentrySdk.Init and logging.AddSentry() from the snippet. On the logs setup and options includes, move dotnet.azure-functions-worker into the UseSentry + EnableLogs sections and add dotnet.extensions-hosting to them, for the generic-host guide. The Microsoft.Extensions.Logging section now says that generic-host apps use UseSentry from Sentry.Extensions.Hosting instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new Generic Host guide (#20311) starts Sentry with UseSentry, so its logs usage page should show the ILogger section like the other host integrations, and its requirements start at 7.0.0. Also say that generic host apps set EnableLogs to send ILogger entries. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
<!-- Keep the urgency section so automation can prioritize this PR. You may delete other sections you don't need. --> ## DESCRIBE YOUR PR This PR adds the migration guide for version 7 of the Sentry SDK for .NET, ready for the public release candidate, `7.0.0-rc.2`. It follows the pattern of the Flutter v10 guide from #19390: - A full guide at `/platforms/dotnet/migration/v6-to-v7/`, built from one include per change in `includes/migration/dotnet-v7/`. - An interactive checklist at `/platforms/dotnet/migration/v6-to-v7/interactive/` that renders the same includes through `<MigrationGuide migration="dotnet-v7" />`. - An agent prompt callout that points at the guide's `.md` URL. - A "Migrating to 7.x" section at the top of the existing .NET migration page, which links to both. Both pages live under `common/`, so they render for every .NET guide, such as ASP.NET Core, MAUI, WPF and Serilog. Xamarin uses a separate SDK, so the new pages exclude it. I didn't move the 6.x, 4.x and 3.x sections, so every existing URL and anchor keeps working and the PR needs no redirects. To register the collection, the PR adds `dotnet-v7` to the `MIGRATIONS` map in the `MigrationGuide` component and to the validator's `COLLECTIONS` map, with specs for both. These changes in `src/components/migrationGuide/` and `scripts/` touch code that the JavaScript and Flutter guides share, so they need an approval from the docs team. For reference, msonnb approved the last change to the component in #19729, and andreiborza approved the JavaScript interactive guide that added it in #19076. The checklist shows one step only on the MAUI guide. Every other step applies to every .NET guide, because .NET apps combine integrations, such as a Serilog sink in an ASP.NET Core app. I checked the guide against `7.0.0-rc.2` from nuget.org and against the `version7` branch at getsentry/sentry-dotnet@a56c63455. The guide describes 7.0.0. Where rc.2 still behaves differently, the release candidate note at the top says so. ### Why this goes live during the release candidate I'd like to merge this as soon as it's approved, while 7.0 is still in release candidate. 7.0.0 GA is planned for 2026-11-30. People who try the release candidate need the guide now, and the agent prompt needs a published `.md` URL to point at. Two develop-docs rules pull in different directions here. [Managing Linear projects](https://develop.sentry.dev/sdk/getting-started/playbooks/coordination/managing-linear-projects/#visibility-for-major-releases) says docs "MUST NOT go live before the SDK ships". The [breaking changes playbook](https://develop.sentry.dev/sdk/getting-started/playbooks/sdk-lifecycle/breaking-changes/#6-update-docs-and-changelog) says to publish the migration guide "before or alongside the major release". I read the first rule as protecting users from docs for code they can't get. Version `7.0.0-rc.2` is public on nuget.org, and the guide's first block says it's a release candidate and names that version. Other SDKs made the same call: - The Python 2.0 guide merged on 2024-02-28, while only the `2.0.0a1` alpha was out. Its note at the top said so. - The JavaScript v11 guide merged on 2026-09-08 with `11.0.0-beta.1` out, and its interactive version followed on 2026-09-11. - The Flutter v10 guide merged on 2026-10-05 with `10.0.0-rc.2` out, four days before 10.0.0. ### The release candidate note The guide opens with one `<Alert>`. It says there is no stable 7.0 yet, names `7.0.0-rc.2`, and says the rest of the .NET docs describe 6.x until 7.0.0 ships. It also covers what only the release candidate has: - `Logging.AddSentry()` after `ClearProviders()` doesn't add Sentry's logger providers back yet. That came with getsentry/sentry-dotnet#5776, after rc.2. - `DecompressionMethods` still includes Brotli, which getsentry/sentry-dotnet#5816 takes out of the default after rc.2. The note says how to leave it out until then. - An ASP.NET Core app that sends `ILogger` entries through NLog crashes with `Debug` on, tracked in getsentry/sentry-dotnet#5822. The guide's verify step turns `Debug` on, so the note says to leave it off in those apps. - Its `net11.0` builds depend on the .NET 11 release candidate versions of three `Microsoft.Extensions` packages. The rest of the guide describes 7.0.0 as released. At GA, I'll delete that one block from `includes/dotnet-v7-migration-overview.mdx`, and nothing else needs to change. ### What this PR leaves to other PRs This PR only adds the guide and what it needs. The reference pages are in other PRs, and this one doesn't need any of them to merge first: - Logs and the logging integrations: #19925 - `Microsoft.Extensions.Logging` and ASP.NET Core: #19961 - OpenTelemetry propagation: #19924 - Release and environment: #19960 - Hangfire monitor schedules: #19781 Three links in the guide point to the "Apps That Call UseSentry" sections that #19925 adds to the Serilog, NLog and log4net guides. Until #19925 merges, they open those guides at the top, and the migration guide sums up the same setups itself. There is no page for the new `Sentry.Extensions.Hosting` package yet. I'll link it from the guide once that page exists. Refs https://linear.app/getsentry/issue/NET-860 Refs getsentry/sentry-dotnet#5710 ## IS YOUR CHANGE URGENT? Help us prioritize incoming PRs by letting us know when the change needs to go live. Select exactly one option. For deadlines, replace `YYYY-MM-DD` with the due date. You can update this information later by editing the PR description. - [x] Urgent deadline (GA date, etc.): 2026-11-30 - [ ] Other deadline: YYYY-MM-DD - [ ] No deadline: Not urgent, can wait up to 1 week+ ## PRE-MERGE CHECKLIST _Make sure you've checked the following before merging your changes:_ - [ ] Checked Vercel preview for correctness, including links - [ ] PR was reviewed and approved by any necessary SMEs (subject matter experts) - [ ] PR was reviewed and approved by a member of the [Sentry docs team](https://github.com/orgs/getsentry/teams/docs) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com> Co-authored-by: Alex Krawiec <alex.krawiec@sentry.io>
UseSentry starts Sentry when the host is built, so crashes before then aren't sent. Apps using Serilog's two-stage initialization can also call SentrySdk.Init before creating the builder to send them. Refs getsentry/sentry-dotnet#5844 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
As for Serilog: UseSentry starts Sentry when the host is built, so crashes before then aren't sent. Calling SentrySdk.Init before creating the builder, and logging the crash if startup fails, sends them. Refs getsentry/sentry-dotnet#5844 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Warning
Do not merge before sentry-dotnet 7.0.0 is released (planned 2026-11-30).
DESCRIBE YOUR PR
Updates the .NET logging docs for sentry-dotnet 7.0.0. In 7.0.0,
SentryOptions.EnableLogsandSentryOptions.EnableMetricsare removed, Serilog, NLog and log4net send logs as soon as they're added, and the Serilog, NLog, log4net and Microsoft.Extensions.Logging integrations no longer initialize the SDK. The pages are written for 7.x. The docs aren't versioned, so this stays a draft until 7.0.0 ships.platform-includes/logs/*/dotnet.mdx):EnableLogsis only documented on the host options (ASP.NET Core, AWS Lambda, Azure Functions, Blazor Server, Blazor WebAssembly, MAUI). The Serilog, NLog, log4net and Microsoft.Extensions.Logging snippets callSentrySdk.Initand add the integration without a switch. The host and Serilog/NLog/log4net sections explain whenEnableLogssends each log twice.InitializeSdk, and the DSN, environment, release and<options>settings on the NLog target and log4net appender. Documented Serilog'sUseSerilog()and the one-time standard-error warning.dsnfrom the set-tag and set-user variants, including theoptions.Dsnthat feat(docs): Apply new quick start template to .NET quick start guides #19990 added to the set-tag snippet. Deleted the set-environment, set-release and config-intro variants, so the NLog guide uses the generic .NET pages, which set these on the options passed toSentrySdk.Init.builder.Logging.AddSentry(o => o.InitializeSdk = false), which no longer compiles and was already redundant withUseSentry.Sentry.Extensions.Hostinginstead ofSentry.Extensions.Logging, and starts Sentry with.UseSentry(options => ...)on theHostBuilderchain instead oflogging.AddSentry(options => ...).EnableLogs = truestays in the snippet, now onSentryGenericHostOptions. Apps with the ASP.NET Core integration (ConfigureFunctionsWebApplication()) call the sameUseSentry. The "Changed in Version 7.0.0" alert covers 6.x, which has no hosting package.EnableLogsfrom theSentrySdk.Initsnippet and from the list of features the snippet turns on. Send Logs now says the Serilog, NLog and log4net integrations send logs as soon as they're added, and points toSetBeforeSendLogfor dropping them.EnableMetricswas removed in 7.0.0. Kept the advice to returnnullfromSetBeforeSendMetric.Closes getsentry/sentry-dotnet#5698
Part of getsentry/sentry-dotnet#5706
Notes for review
UseSentrystarts Sentry (Document capturing ASP.NET Core startup crashes with Serilog, NLog and log4net in v7.0.0 sentry-dotnet#5844). Each callsSentrySdk.Initbefore the builder; the Serilog one does it alongside Serilog's two-stage initialization. The companion samples, docs(samples): capture startup crashes in the ASP.NET Core Serilog sample sentry-dotnet#5847 and docs(samples): capture startup crashes in the ASP.NET Core NLog sample sentry-dotnet#5866, link to them.masterafter feat(docs): Apply new quick start template to .NET quick start guides #19990, which moved the .NET guides to the new quick start template. The Azure Functions and Blazor WebAssembly changes now sit on that template, which already usesUseOtlp()for Azure Functions.SentrySdk.Initplusbuilder.Logging.AddSentry(), and says in one sentence that generic-host apps useUseSentryfromSentry.Extensions.Hostinginstead. The Microsoft.Extensions.Logging guide page is updated in docs(dotnet): Update Microsoft.Extensions.Logging guide for SDK 7.0.0 #19961, so this PR only partly covers delete hidden DS pages #5706.Sentry.Extensions.HostingwithUseSentry, and says Azure Functions (isolated) apps use it, also with the ASP.NET Core integration. Checked againstversion7:SentryGenericHostOptions.EnableLogsdefaults tofalse, andUseSentryregisters Sentry'sILoggerproviders.ConfigureFunctionsWorkerDefaults()andConfigureFunctionsWebApplication()returnIHostBuilder, so the snippet binds toUseSentry(IHostBuilder, Action<SentryGenericHostOptions>). The SDK starts inBuild()and closes when the host stops. Theversion7sample makes the same call. feat(mel)!: Logging.AddSentry() no longer registers IHub or ISentryClient sentry-dotnet#5740 stopsLogging.AddSentry()from registeringIHub, soUseSentryis now also what puts it in DI.dotnet.extensions-hostingin theUseSentry+EnableLogssections, theappsettings.jsontab and the Serilog/NLog/log4net expandables. That's the platform key of the generic-host guide coming in a separate PR, so that PR doesn't need to edit these files. Nothing links to it yet, since the page doesn't exist on this branch. Azure Functions isn't in the Serilog/NLog/log4net expandables: their snippets usebuilder.Servicesandbuilder.Logging, which aHostBuilderchain doesn't have.EnableLogsoption, and the Azure Functions guide.EnableLogson. That only happens whenILoggerentries reach both Sentry's provider and Serilog. I checked againstversion7: oneLogInformationcall was sent once withbuilder.Host.UseSerilog(), which replaces the logger factory, and twice withbuilder.Logging.AddSerilog(). The same applies to NLog and log4net when they're registered asILoggerproviders. So the docs name that case, registering the framework as anILoggerprovider (for examplebuilder.Logging.AddSerilog()), and say to leaveEnableLogsoff then.UseSerilog()as the replacement forApplySerilogScopeToEvents(). Onversion7it's optional: if the app doesn't call it, the sink registers the scope processor itself once it's running, so only events captured before then miss theLogContextproperties. The guide says so.dotnet.blazor-serveradded to theEnableLogssections. It usesSentry.AspNetCore'sUseSentry, but it fell into the plainSentrySdk.Initsection, which now says logging integrations need no switch.SentryAppender.Environment, which 7.0.0 removes (feat(log4net)!: the Sentry appender no longer initializes the SDK sentry-dotnet#5592).new User. That type doesn't exist, so it's nowSentryUser.TracesSampleRateandDisableSentryHttpMessageHandler, which theversion7sample still sets. UnderUseOtlp()Sentry creates no transactions of its own, soTracesSampleRatehas no effect.SentryHttpMessageHandleralready skips span creation, so disabling it would only stop it propagatingsentry-trace. docs(dotnet): Update OTLP propagation docs for SDK 7.0.0 #19924 documents both.version7sources. The Azure Functions andUseSentryones compile against the 7.0.0-rc.2 packages, whose public API matchesversion7.IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
Select exactly one option. For deadlines, replace
YYYY-MM-DDwith the due date. You can update this information later by editing the PR description.🤖 Generated with Claude Code