feat(mel)!: the Microsoft.Extensions.Logging integration no longer initializes the SDK

[jamescrosswell]

The Microsoft.Extensions.Logging portion of #5245, stacked on #5592 (log4net) and following the same design. AddSentry now only wires up the logger providers; Sentry has to be initialized separately via SentrySdk.Init, UseSentry, etc.

This is the last of the four logging integrations, so it closes the issue.

Closes #5245

Tip

Background for reviewers on how Sentry gets initialised today, and why this PR splits SentryLoggingOptions: #5595 (comment)

Changelog Entry

• The Microsoft.Extensions.Logging integration no longer initializes the SDK. Sentry must now be initialized separately from the logging integration (using SentrySdk.Init or UseSentry) - #5595
• Sentry's logging configuration section (Logging:Sentry) now only configures the logging integration. Core SDK settings there, such as Dsn, no longer have any effect and fail at startup with migration guidance: move them to the Sentry section, or pass them where Sentry is initialized - #5595
• Blazor WebAssembly's logger now respects the MinimumEventLevel, MinimumBreadcrumbLevel, log entry filters and ConfigureScope callbacks set in UseSentry - #5595

Breaking changes

• SentryLoggingOptions no longer derives from SentryOptions, matching the Serilog and NLog options. It carries only MinimumBreadcrumbLevel, MinimumEventLevel and log entry filters, so builder.Logging.AddSentry(o => o.Dsn = "…") now fails with a migration error instead of silently doing nothing. Core SDK settings go on the options used to initialize Sentry.
• SentryLoggingOptions.ConfigureScope is removed. Call SentrySdk.ConfigureScope after initializing Sentry.
• ILoggingBuilder.AddSentry(string dsn) no longer initializes Sentry. It is kept as an obsolete-as-error tombstone that throws NotSupportedException with migration guidance, so both code callers and reflection-based callers fail loudly.
• ILoggerFactory.AddSentry(…) no longer initializes Sentry, replaces the current hub, or assigns a MelDiagnosticLogger as the SDK's DiagnosticLogger.
• InitializeSdk no longer has any effect. SentryLoggingOptions.Dsn and SentryLoggingOptions.InitializeSdk are kept as tombstones that throw when set, including when they are bound from the Sentry configuration section, so an app that upgrades with a config-bound DSN fails at startup instead of silently reporting nothing. On the framework options it is gone entirely.
• SentryAspNetCoreOptions, SentryMauiOptions and SentryBlazorOptions now derive from a new abstract SentryHostOptions : SentryOptions. They still have MinimumBreadcrumbLevel, MinimumEventLevel, ConfigureScope and AddLogEntryFilter, and the same keys still bind from the Sentry configuration section, so existing UseSentry callbacks and appsettings.json files keep working. Code that treats them as a SentryLoggingOptions no longer compiles.
• The logging configuration section no longer configures the SDK. Logging:Sentry binds MEL's own LogLevel rules plus MinimumEventLevel and MinimumBreadcrumbLevel; any other key there throws NotSupportedException naming the offending keys. Core SDK settings still bind from the root Sentry section for the integrations that initialize Sentry, which is where every sample and docs guide already puts them.
• ServiceCollectionExtensions.AddSentry<TOptions> now requires TOptions : SentryHostOptions.
• builder.Logging.AddSentry() no longer registers SentryOptions in the service collection, so resolving SentryOptions from DI on that path now throws. The MEL integration no longer owns an options object that initializes the SDK. The integrations that do initialize still register it.
• ConfigureScope callbacks on the framework options now run when Sentry is initialized, rather than when the Sentry logger provider is first created.
• An AddSentry(o => …) call that only sets logging settings still compiles, and on 6.x it initialized the SDK itself, taking the DSN from SENTRY_DSN or a [Dsn] assembly attribute. The integration therefore warns at runtime — on the first log event that would have become a Sentry event, if Sentry is not initialized but a DSN can still be found, it writes one line to standard error, at most once per logger provider. Microsoft.Extensions.Logging has no self-diagnostics channel, so standard error is the only one available; the shared policy lives in Sentry.Internal.UninitializedSdkWarning, added in feat(serilog)!: the Sentry sink no longer initializes the SDK #5573. SentryLogger.Log also now reads IHub.IsEnabled once per call instead of twice.

Before:

var builder = Host.CreateApplicationBuilder();
builder.Logging.AddSentry("https://key@sentry.io/1");

After:

var builder = Host.CreateApplicationBuilder();

using var sentry = SentrySdk.Init(o => o.Dsn = "https://key@sentry.io/1");

builder.Logging.AddSentry();

Fixes

• Blazor WebAssembly's logger ignored the logging settings in UseSentry. Blazor registered the plain MEL logger provider, which dependency injection built from a separate, default IOptions<SentryLoggingOptions> rather than the SentryBlazorOptions configured in UseSentry. MinimumEventLevel, MinimumBreadcrumbLevel, log entry filters and ConfigureScope were all silently ignored by the logger; SDK initialization itself was unaffected. The same bug exists on main.
• ASP.NET Core ran its options setup twice. UseSentry registered SentryAspNetCoreOptionsSetup twice, once with the root Sentry section and once with the logging provider configuration (Logging:Sentry). Different sections, but the same setup class, so everything its Configure adds beyond binding was applied twice: two Kestrel deduplication log filters and two TraceIgnoreStatusCodeTransactionProcessor instances. The setup now binds the Sentry section once, and the logging section gets its own setup that only applies logging settings. On netstandard2.0 the section was bound by a plain Configure<SentryAspNetCoreOptions>(section) call and the setup ran once, so the extras were already applied once there; that branch is gone, and the setup now runs once on every target.
• Configuration could override Blazor WebAssembly's platform defaults. DetectStartupTime, RequestBodyCompressionLevel and IsGlobalModeEnabled are set because Blazor WASM requires them (System.Diagnostics.Process isn't supported there, and HttpClientHandler can't compress), but they are applied in the same Configure delegate as the UseSentry callback, which was registered before the configuration binding. IConfigureOptions<T> run in registration order, so a Sentry:DetectStartupTime key in wwwroot/appsettings.json won over the platform default, reintroducing the PlatformNotSupportedException it exists to avoid - and configuration won over anything set in UseSentry, the opposite of ASP.NET Core. The setups are now registered first, so precedence runs from the Sentry section, through Logging:Sentry, to the callback and the platform defaults. version7 has the same inversion, where the generic AddSentry<SentryBlazorOptions>(delegate) registered the callback before its options setup.
• Structured logs from plain MEL took default attributes from the wrong options. This came from the first commit on this branch: sentry.environment, sentry.release and server.address were read from SentryLoggingOptions, which the SDK was no longer initialized with. The structured logger now reads them from the hub.

Notes for review

• UseSentry no longer loses a TryAdd race with Logging.AddSentry(). The logging integration registers a non-initializing Func<IHub>, so whichever call ran first used to win. Calling builder.Logging.AddSentry() before UseSentry left the SDK disabled with no indication, where v6 failed loudly at startup with "You must supply a DSN". The initializing registration now replaces any existing accessor, so order no longer matters; both orders are tested. Calling both is still redundant and still registers two pairs of logger providers, unchanged from v6. MAUI was never affected, since it initializes in SentryMauiInitializer rather than through the hub accessor.

• Why SentryHostOptions. SentryLoggingOptions was doing two jobs: configuring the MEL logger, and acting as the base class for integrations that initialize the SDK. Splitting them is what lets SentryLoggingOptions go standalone. The host options pass the log levels and filters through to an inner SentryLoggingOptions instance (the same object, not a copy), and that is what their logger providers receive.

• Why abstract. It's the natural options type for a generic-host init path (Add a non-logging way to initialise Sentry in generic host apps #5572). Making it concrete later is additive; the reverse would be breaking. It lives in Sentry.Extensions.Logging because that's the one package ASP.NET Core, MAUI and Blazor all reference. Where it ultimately belongs is the packaging question Add a non-logging way to initialise Sentry in generic host apps #5572 raises.

• ConfigureScope timing. For MAUI and Blazor, the only thing that applied these callbacks used to be the MEL logger provider's constructor, gated on hub.IsEnabled when the provider was built. They're now applied right after init: in AddSentry<TOptions>'s hub factory (ASP.NET Core, Blazor) and in SentryMauiInitializer (MAUI). ASP.NET Core still also applies them per request in SentryMiddleware, and gRPC in its interceptor.

• SDK name. SentryLoggerProvider no longer stamps Sdk.Name/Sdk.Version, pushes a scope, or disposes the hub. Per Metrics and SentrySdk.Logger logs emitted during a request carry no sentry.sdk.name/sentry.sdk.version on ASP.NET Core #5497 the SDK name identifies the integration that initialized the hub, and the logging integration is identified by the origin (auto.log.extensions_logging). ASP.NET Core, MAUI and gRPC set their own names, so they are unaffected; Blazor WebAssembly has none of its own, which is Blazor WebAssembly apps don't report a Blazor SDK name #5613.

• Migration guard. Mirrors feat(serilog): configuring a DSN on the sink now fails with a migration error #5611 (Serilog) and the NLog and log4net guards on this stack. A single SentryLoggingConfiguration now binds the logging section on every target framework: it applies the two levels, ignores MEL's own LogLevel rules, and throws for anything else - the obsolete-as-error message for Dsn or InitializeSdk: true, and a message naming the offending keys otherwise. That replaces BindableSentryLoggingOptions and the separate netstandard2.0 reflection path, which is what made the tombstone setters value-dependent (the configuration binder writes each property's own value back, and the unconditional version broke Windows CI earlier on this branch). The setters stay value-dependent, since anyone can still call configuration.Bind(options) themselves.

• Which configuration each integration reads. The integrations that initialize Sentry read Logging:Sentry from the app's configuration rather than through ILoggerProviderConfiguration, because an app that passes the whole configuration to AddConfiguration - as Sentry.Google.Cloud.Functions does - makes the root Sentry section part of the provider section, and every core setting in it would then be rejected. Plain MEL keeps the provider configuration, where rejecting core settings is right: nothing else binds them onto SentryLoggingOptions, so they really would be ignored.

• InitializeSdk. MAUI initializes in SentryMauiInitializer, so it calls an internal non-initializing overload of AddSentry<TOptions> instead of setting a flag. Tests that set InitializeSdk = false to avoid initializing now use DisableSdkDsnValue. UseSentry_OptionsNotInitializeSdk_DisabledSdk tested the flag itself and is deleted; UseSentry_DisableDsn_DisabledSdk still covers a disabled SDK.

• Blazor registrations. UseSentry now delegates to an internal ILoggingBuilder extension so it can be unit tested (WebAssemblyHostBuilder needs a browser runtime). The providers are registered by factory so they keep their existing types, and with them the existing provider alias and filter configuration. Configuration binding moved to a small SentryHostOptionsSetup<TOptions> in Sentry.Extensions.Logging, which has the configuration-binding source generator enabled, since Blazor WASM is trimmed.

• New tests.

  • The DI init path runs ConfigureScope callbacks, and the non-initializing path doesn't.
  • MAUI ConfigureScope data reaches events. Nothing tested that before.
  • The Blazor logger respects MinimumEventLevel.
  • The Sentry section configures both halves of the host options, the logging section configures only the logging half, a core setting there throws, and the section's extras are applied once.
  • An app that hands its whole configuration to AddConfiguration still gets its root Sentry section bound rather than rejected.
  • Every public setter on SentryLoggingOptions is a key the logging section accepts, so a new logging option can't be mistaken for an SDK setting.
  • Blazor's platform defaults survive configuration keys that would otherwise replace them, and the UseSentry callback wins over configuration while configuration still applies to what the callback leaves alone.

  Each test was checked to fail with its fix reverted.

• The ApplyDefaultTags tests only used SentryLoggingOptions as a vehicle for a core SentryOptions method; they moved to SentryOptionsTests.

• The structured-logger tests now give their mocked hub options through SentryOptionsForTestingOnly and reset it afterwards. The MEL provider test previously passed only because another test class happened to leave it set.

• builder.Logging.AddSentry(dsn) was the only way to initialize Sentry in a generic-host app, so samples/Sentry.Samples.GenericHost now calls SentrySdk.Init directly. Add a non-logging way to initialise Sentry in generic host apps #5572 tracks the replacement and should land before this ships.

• samples/Sentry.Samples.GenericHost kept its log levels in the root Sentry section and passed the whole configuration to builder.Logging.AddConfiguration, which is how they reached the logging integration. They now live under Logging:Sentry, and that call is gone.

• SentryWebHostBuilderExtensionsTests' IConfiguration substitute returned "" for every key, where configuration returns null for an absent one. It now returns null, which removed a #if NET8_0-only workaround in UseSentry_Logging_AddLoggerProviders.

• ApiApprovalTests.Run.Net4_8 can't regenerate on macOS. It was byte-identical to the other snapshots before this change, so it's a copy of the regenerated one.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 95.89041% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.07%. Comparing base (af47132) to head (d3a2159).

Files with missing lines	Patch %	Lines
...or.WebAssembly/WebAssemblyHostBuilderExtensions.cs	88.88%	2 Missing ⚠️
.../Sentry.Extensions.Logging/SentryLoggingOptions.cs	75.00%	1 Missing and 1 partial ⚠️
src/Sentry.Extensions.Logging/SentryLogger.cs	93.75%	0 Missing and 1 partial ⚠️
...entry.Extensions.Logging/SentryStructuredLogger.cs	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                            Coverage Diff                             @@
##           feat/no-init-from-logging-log4net-5245    #5595      +/-   ##
==========================================================================
+ Coverage                                   74.96%   75.07%   +0.10%     
==========================================================================
  Files                                         515      519       +4     
  Lines                                       18832    18872      +40     
  Branches                                     3655     3658       +3     
==========================================================================
+ Hits                                        14118    14168      +50     
+ Misses                                       3855     3840      -15     
- Partials                                      859      864       +5     

☔ 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]

Some background for reviewers on why this PR splits the options class.

Initialising Sentry

Generally Sentry's integrations fall into two camps:

1. Integrations for features (e.g. databases)
2. Integrations for platforms (e.g. ASP.NET Core or MAUI)

As a rule, we provide UseSentry extensions on the Builders for the platforms that let you initialise the Sentry SDK at the same time as configuring the Sentry integration for those platforms. We pass a Sentry DSN into the UseSentry method which is used to initialise a Sentry Hub and Client that will be used to send captured information (errors, traces etc.) to the SDK user's Sentry project... and typically there are a bunch of other options specific to that platform that can be set at the same time.

For people not using any specific platform, they can instead initialise Sentry by calling SentrySdk.Init.

One of the features that Sentry supports is logging and it's such a common feature that we decided it might be convenient if people could initialise both logging and the Sentry SDK in a single call (e.g. when using Sentry in a console application, where you also have logging).

In theory that was fine. In practice it's caused huge headaches (see #5245). If you use Serilog and ASP.NET Core, you have to tell Serilog "send logs, but don't initialise — ASP.NET Core already did that". Users constantly get this wrong, and so did we. So in v7, we're removing the ability to initialise the SDK from the logging integrations. These will now be initialised the same as all the other 'feature' integrations we do.

The old way

In version 6 the options classes look something like this:

classDiagram
    SentryOptions <|-- SentryLoggingOptions
    SentryLoggingOptions <|-- SentryAspNetCoreOptions
    SentryLoggingOptions <|-- SentryMauiOptions
    SentryLoggingOptions <|-- SentryBlazorOptions

Loading

SentryLoggingOptions in that diagram does two things: the options type for the MEL integration, and the base class for the ASP.NET Core, MAUI and Blazor options. Those integrations genuinely need to initialise the SDK so they still need an options class that contains a DSN. But in version 7.0 we don't want the options class used to initialise the MEL integration to have a DSN on it since people shouldn't be initialising the Sentry SDK via that integration anymore.

The new way

As such, in version 7.0 we're splitting that options class up:

• SentryLoggingOptions — now standalone, covering only "which log entries go to Sentry" (two minimum levels plus filters). It no longer inherits SentryOptions, so you cannot set a DSN on it. This is the options class that will be used to initialise MEL in v7.
• SentryHostOptions (src/Sentry.Extensions.Logging/SentryHostOptions.cs, the new file) — inherits SentryOptions, so it has the DSN, release, sampling and so on, and is the base for integrations that own initialisation. It also exposes the log-level settings, forwarding them to a SentryLoggingOptions it holds internally, so existing UseSentry(o => o.MinimumEventLevel = ...) code and appsettings.json keep working unchanged... we avoid breaking people's existing code.

classDiagram
    SentryOptions <|-- SentryHostOptions
    SentryHostOptions <|-- SentryAspNetCoreOptions
    SentryHostOptions <|-- SentryMauiOptions
    SentryHostOptions <|-- SentryBlazorOptions
    SentryHostOptions *-- SentryLoggingOptions : holds internally

Loading

[jamescrosswell]

Just a note on why SentryHostOptions.Logging is a composite property:

1. SentryLoggingOptions must be a concrete public class. It's what users configure in builder.Logging.AddSentry(o => …), and when using MEL IOptions<SentryLoggingOptions> resolves from DI for the options binding. IOptions<T> is constrained to class, new(), so this can't be an interface.
2. SentryHostOptions has to be a SentryOptions. It's the object handed to SentrySdk.InitHub... so it can't descend from SentryLoggingOptions - that's kind of the whole point of this PR stack - removing the DSN (and options that are used for SDK initialisation) from the options that are used to initialise the logging integrations.

[jamescrosswell]

The hub plumbing on the logging path is temporary

Worth recording why this PR fixes the TryAdd race rather than removing its cause.

Logging.AddSentry() still registers more than logging: Func<IHub>, IHub, ISentryClient and the HttpClientFactory instrumentation (SentryHttpMessageHandlerBuilderFilter). That's a leftover from when the logging integration initialised the SDK. Because both paths registered the hub accessor with TryAdd, whichever ran first won, so calling builder.Logging.AddSentry() before UseSentry left the SDK silently disabled — where v6 at least failed loudly with "You must supply a DSN".

This PR makes the initializing registration replace any existing accessor, so the order of the two calls no longer matters. That's deliberately targeted, not the end state.

The end state is #5572: the host-level init path takes ownership of the hub plumbing, ISentryClient and the HttpClient instrumentation, and Logging.AddSentry() registers only its two ILoggerProviders — which can take HubAdapter.Instance directly, the same "never capture a hub, always dereference the current one" contract Func<IHub> provides today (#157). At that point nothing competes for the accessor and the RemoveAll here becomes belt-and-braces.

It can't be done in this PR: builder.Logging.AddSentry() is currently the only thing registering those services for generic-host apps, so removing them before #5572 exists would take the capability away with nothing to move to. #5572 has been updated with that scope, and #5645 covers the regression tests for the multiple-container-build behaviour (#103, fixed by #157) that this plumbing defends and that nothing currently pins — worth landing before the restructuring.

Same reasoning applies to SentryHostOptions living in Sentry.Extensions.Logging in this PR: it's the one package ASP.NET Core, MAUI and Blazor all reference. Where it ultimately belongs is part of #5572's packaging question.

[ric-oliv]

I ran the test projects this touches, and the inline comments cover what I found. Events from the logging integration also lose nuget:Sentry.Extensions.Logging in sdk.packages, which #5649 tracks.

Up to you if we include these changes, otherwise looks great! ✅

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 04a5a54. Configure here.}

[ric-oliv]

Very nice!