[ric-oliv]

In v7, the Microsoft.Extensions.Logging integration no longer initializes Sentry (#5595), but Logging.AddSentry() still registered IHub, ISentryClient and Func<IHub> in DI, a leftover from when it did. They belong to whatever initializes Sentry. Every UseSentry already registers them: ASP.NET Core, MAUI, Blazor WebAssembly, and the generic host from #5739. This removes them from the logging path, as planned in #5572.

What changes

• Logging.AddSentry() registers its two logger providers and the HttpClientFactory filter, nothing else. The providers use HubAdapter.Instance, which always forwards to the current hub, as the Func<IHub> accessor did (Failure to capture event: System.ObjectDisposedException: Cannot access a disposed object. #103).
• The HttpClientFactory filter stays, so apps that only call Logging.AddSentry() keep their outgoing-HTTP breadcrumbs and spans.
• With a host integration present, Logging.AddSentry() still warns that it's redundant (fix!: apps that call both UseSentry and Logging.AddSentry() no longer capture each error, breadcrumb and log twice #5694). That branch still resolves IHub from DI when it's registered: the host integration registers it, and resolving it starts the SDK, so the warning shows in either call order.
• AddSentryHub is now private, since AddSentry<TOptions> is its only caller.

Changelog Entry

• builder.Logging.AddSentry() no longer registers IHub, ISentryClient or Func<IHub> in the service collection. UseSentry registers them; apps that initialize Sentry with SentrySdk.Init and inject them now register them themselves

Breaking changes

An app that calls only SentrySdk.Init and Logging.AddSentry() and injects IHub, ISentryClient or Func<IHub> now fails when DI resolves them. For a hosted service, that's when the host starts:

System.InvalidOperationException: Unable to resolve service for type 'Sentry.IHub' while attempting to activate 'Worker'.

The code still compiles. The fix is UseSentry. Where it isn't available, such as Host.CreateApplicationBuilder() on .NET Framework (#5739 adds UseSentry only on IHostBuilder there), register them:

using Sentry;
using Sentry.Extensibility;

builder.Services.AddSingleton<IHub>(HubAdapter.Instance);
builder.Services.AddSingleton<ISentryClient>(HubAdapter.Instance);
builder.Services.AddSingleton<Func<IHub>>(() => HubAdapter.Instance); // only if the app injects Func<IHub>

That's the same object the logging path used to return. I checked it against this change with a scratch app on net10, on the netstandard2.0 builds, and on .NET Framework 4.8 with Host.CreateApplicationBuilder() from Microsoft.Extensions.Hosting 8.0. Without the lines, the host fails to start as above. With them, capture through each type reaches the SDK, follows a second SentrySdk.Init, and keeps working after a second container is built and disposed.

Impact

• Who's affected: only logging-only apps that inject the hub. Every host integration (ASP.NET Core, Google Cloud Functions, MAUI, Blazor WebAssembly, the generic host) registers it through AddSentry<TOptions>, not the logging path. No sample resolves it on the logging-only path.
• Failure mode: loud. A DI error names Sentry.IHub; no events are dropped silently.
• OpenTelemetry: the obsolete TracerProviderBuilder.AddSentry() takes IHub from DI and falls back to SentrySdk.CurrentHub. On the logging-only path it now takes that fallback, so the span processor holds the hub that's current when the tracer provider is built rather than HubAdapter. That only makes a difference if the app initializes Sentry again afterwards.
• Hot paths and memory: no change. Each provider gets HubAdapter.Instance once, at creation, instead of resolving it from DI.

Tests

• LoggingBuilderExtensionsTests: the logging path registers no hub; a logger created before a second SentrySdk.Init sends to the new hub; HttpClientFactory still gets the Sentry handler.
• ServiceCollectionExtensionsTests: the two regression tests from test: pin the multiple-container behaviour behind Func<IHub> #5646 keep their host case. Their logging-only case had a resolved hub to check, which no longer exists; the tests above cover that path. New: with both AddSentry<TOptions> and Logging.AddSentry(), HttpClientFactory gets one Sentry handler.
• LoggingTests gets the hub from SentrySdk instead of DI.
• Each new test fails when the behavior it covers is removed (checked by changing the code and running it). The ASP.NET Core test for the redundant-call warning fails if that branch reads the options through HubAdapter.Instance.

Part of #5572.

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 75.68%. Comparing base (1ce152c) to head (6ac720a).
⚠️ Report is 1 commits behind head on version7.

Files with missing lines	Patch %	Lines
...try.Extensions.Logging/LoggingBuilderExtensions.cs	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           version7    #5740      +/-   ##
============================================
+ Coverage     75.60%   75.68%   +0.08%     
============================================
  Files           522      525       +3     
  Lines         19042    19132      +90     
  Branches       3679     3694      +15     
============================================
+ Hits          14396    14480      +84     
- Misses         3810     3812       +2     
- Partials        836      840       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jamescrosswell]

LGTM