[jamescrosswell]

Warning

Do not merge before sentry-dotnet 7.0.0 is released (planned 2026-11-30).

DESCRIBE YOUR PR

Adds a Generic Host guide for Sentry.Extensions.Hosting, which sentry-dotnet 7.0.0 adds (getsentry/sentry-dotnet#5739). In 7.0.0, Logging.AddSentry() no longer initializes the SDK. Worker services, console apps on the generic host, Windows services and Azure Functions (isolated) apps call UseSentry from this package instead. The page is written for 7.x. The docs aren't versioned, so this stays a draft until 7.0.0 ships.

The guide follows the quick start template from #19990 and covers:

• UseSentry on IHostApplicationBuilder and IHostBuilder, the Sentry and Logging:Sentry sections, and why not to call Logging.AddSentry() as well
• the host environment, "Dsn": "", and when the SDK starts (Build()) and closes (ApplicationStopped)
• ClearProviders() ordering (fix(hosting): start the SDK during Build() even when the app clears or replaces logger providers sentry-dotnet#5772, fix(logging): make Logging.AddSentry() work after UseSentry and ClearProviders() sentry-dotnet#5776, fix(logging): warn when ClearProviders() removes the logger providers UseSentry added sentry-dotnet#5789, docs: add an ASP.NET Core NLog sample and stop advising AddSentry() when another integration handles ILogger sentry-dotnet#5821)
• ASP.NET Core and MAUI apps, and the static UseSentry call that Aspire's AddServiceDefaults needs
• the .NET Framework gap, with the SentrySdk.Init and Logging.AddSentry() fallback and its HubAdapter.Instance registrations (feat(mel)!: Logging.AddSentry() no longer registers IHub or ISentryClient sentry-dotnet#5740)
• replacing SentrySdk.Init, briefly. The migration guide (docs(dotnet): Add 6.x to 7.x migration guide for 7.0.0-rc.2 #20143) covers upgrades.

It also adds platform-includes/configuration/config-intro/dotnet.extensions-hosting.mdx, so the guide's Options page starts with UseSentry instead of SentrySdk.Init.

Closes getsentry/sentry-dotnet#5707

Notes for review

• Registration. A new .NET guide only needs its index.mdx. The platform key dotnet.extensions-hosting comes from the folder name, guides without sidebar_order, like the other .NET guides, are listed by title, and the icon falls back to the .NET one, as for the Microsoft.Extensions.Logging, Serilog and NLog guides. The page is new, so it needs no redirects.
• Package version. The install snippets use packages.version('sentry.dotnet'), because the release registry has no sentry.dotnet.extensions.hosting entry yet. Until 7.0.0 is out, the preview shows 6.12.1, which doesn't exist for this package. Once the registry has the package, switch to its own key. The sdk: frontmatter already uses sentry.dotnet.extensions.hosting (from Constants.cs). Without a registry entry, the page just has no package details box.
• Shared includes that render wrongly for dotnet.extensions-hosting. I left them alone, since other PRs own them:
  • platform-includes/logs/setup/dotnet.mdx falls into the SentrySdk.Init section instead of UseSentry with EnableLogs. docs(dotnet): Update logging docs for SDK 7.0.0 #19925 is adding the key to the host sections.
  • platform-includes/logs/options/dotnet.mdx shows the generic EnableLogs text and leaves out "Configure Microsoft.Extensions.Logging Filters". Same PR.
  • platform-includes/logs/usage/dotnet.mdx shows only the SentrySdk.Logger APIs. The key belongs in the ILogger section too.
  • platform-includes/logs/requirements/dotnet.mdx says logs need SDK version 5.14.0. This package starts at 7.0.0.
• Additions to the brief from the version7 source:
  • "Dsn": "" turns the SDK off, but SENTRY_DSN still wins over an empty Dsn (SettingLocator.GetDsn). The page says so.
  • Logging:Sentry only accepts LogLevel, MinimumBreadcrumbLevel and MinimumEventLevel. Any other key makes Build() throw NotSupportedException. With no DSN anywhere, Build() throws ArgumentNullException.
  • Calling Sentry.AspNetCore's UseSentry twice still sends each error twice (a follow-up in feat: add Sentry.Extensions.Hosting with UseSentry for generic host apps sentry-dotnet#5739). The Aspire section says not to call it again in Program.cs.
• Azure Functions gets one line in the intro. The Azure Functions guide still shows logging.AddSentry(...). docs(dotnet): Update logging docs for SDK 7.0.0 #19925 owns it.
• Links to add once the other PRs merge:
  • Microsoft.Extensions.Logging guide: send generic host apps here, from the "If you use a host integration such as ASP.NET Core or MAUI" paragraph. Its Sentry.Samples.GenericHost sample link belongs here too, since the sample now calls UseSentry.
  • Azure Functions guide: link here from the UseSentry setup.
  • platform-includes/logs/integrations/dotnet.mdx: add Generic Host to the list.
  • docs/product/logs/getting-started/index.mdx and docs/product/metrics/getting-started/index.mdx: add Generic Host to the .NET lists.
  • Migration guide, "Generic Host Apps Call UseSentry": link to this page.
• The sample link points at main, where Sentry.Samples.GenericHost keeps the 6.x setup until version7 is merged.
• The C# snippets compile against version7, on net10.0, and on net48 for the IHostBuilder example and the .NET Framework fallback. On net48, UseSentry on HostApplicationBuilder fails with CS1929, as the page says.

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.): 2026-11-30
• Other deadline: YYYY-MM-DD
• No deadline: Not urgent, can wait up to 1 week+

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
sentry-docs	Ready	Preview	Oct 29, 2026 6:42am UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
develop-docs	Ignored		Oct 29, 2026 6:42am UTC

[ric-oliv]

Readers coming from Send Logs will look for EnableLogs here, and the IHub error is what people search for when they miss the registrations. What do you think about naming both?

Suggested change

The app can also keep `Host.CreateApplicationBuilder()`, initialize Sentry with `SentrySdk.Init`, and add the logging integration with `builder.Logging.AddSentry()`. It then doesn't read the `Sentry` section, and Sentry doesn't start and close with the host. `Logging.AddSentry()` doesn't register `IHub`, `ISentryClient`, or `Func<IHub>`, so register them if your services inject them:

The app can also keep `Host.CreateApplicationBuilder()`, initialize Sentry with `SentrySdk.Init`, and add the logging integration with `builder.Logging.AddSentry()`. It then doesn't read the `Sentry` section, and Sentry doesn't start and close with the host. It also sends `ILogger` entries as logs, and `EnableLogs` can't turn that off, because it only exists on the `UseSentry` options. `Logging.AddSentry()` doesn't register `IHub`, `ISentryClient`, or `Func<IHub>`. If your services inject them, register them, or the host fails to start with `Unable to resolve service for type 'Sentry.IHub'`:

[jamescrosswell]

Logging.AddSentry() doesn't register IHub, ISentryClient, or Func<IHub>. If your services inject them, register them, or the host fails to start with Unable to resolve service for type 'Sentry.IHub':

That's a bit confusing to me. I think it should probably be in it's own section and we should just tell people what to do in order to get it right... it starts getting confusing when we describe all the things that could go wrong and what happens in those situations.

Depends if we're writing this for humans or LLMs though. LLMs are fine with a long list of seemingly unrelated statements. The docs here are generally to help people get up and running quickly though - LLMs can just read the source code to debug issues.

[ric-oliv]

Apps that call SentrySdk.Init with Logging.AddSentry(), like the fallback above, stop sending logs after the switch until they set EnableLogs. Maybe worth a sentence here:

Suggested change

If your app calls `SentrySdk.Init`, remove that call when you add `UseSentry`, and move its options into the `UseSentry` callback or the `Sentry` section. Whichever initialization runs last wins, and the two don't merge their options.

If your app calls `SentrySdk.Init`, remove that call when you add `UseSentry`, and move its options into the `UseSentry` callback or the `Sentry` section. Whichever initialization runs last wins, and the two don't merge their options. If it also calls `Logging.AddSentry()`, remove that call too. That setup sends `ILogger` entries as logs without any option, while `UseSentry` needs `EnableLogs` set to `true`.

[jamescrosswell]

If it also calls Logging.AddSentry(), remove that call too. That setup sends ILogger entries as logs without any option, while UseSentry needs EnableLogs set to true.

Again, this starts to confuse me... reading the whole paragraph I come away not knowing what it was trying to tell me - possibly it's trying to communicate 3 different things, none of which I feel like I can digest without source code samples.... like:

## Correct

Do this...

## False

Don't do this or this will happen

## False

Don't do this or that will happen

I think that kind of prose is appropriate in github issues where we're trying to get to the bottom issues but we should try to keep the docs here as clear and concise as possible. It it's hard to read, that maybe indicates we've stuffed up the API design.

[ric-oliv]

AddLogEntryFilter works on the UseSentry options too. If #19961 drops its Generic Host content, this page is the only place left that shows it. Maybe something like:

Suggested change

	`EnableLogs` doesn't change how errors and breadcrumbs are captured. Entries at `Error` and above are sent as events, and entries at `Information` and above are kept as breadcrumbs. To change that, set `MinimumEventLevel` and `MinimumBreadcrumbLevel`.
	`EnableLogs` doesn't change how errors and breadcrumbs are captured. Entries at `Error` and above are sent as events, and entries at `Information` and above are kept as breadcrumbs. To change that, set `MinimumEventLevel` and `MinimumBreadcrumbLevel`.
	To drop specific entries before they become breadcrumbs or events, add a filter with `AddLogEntryFilter`. Return `true` to drop the entry:
	```csharp {filename:Program.cs}
	using Sentry.Extensions.Logging;
	builder.UseSentry(options =>
	{
	options.AddLogEntryFilter((category, level, eventId, exception) =>
	exception is OperationCanceledException);
	});
	```

[jamescrosswell]

To drop specific entries before they become breadcrumbs or events, add a filter with AddLogEntryFilter

This bit's good. We could link to the docs for that option rather than trying to re-explain it here (which means two different copies of the same explanation to keep in sync)?