[ric-oliv]

Follow-up to the open question on #5573: how to stop Serilog.Settings.Configuration users silently losing their DSN when they upgrade.

Instead of adding an IConfiguration parameter to the sink method, this keeps a dsn-first overload as a tombstone — [Obsolete(..., error: true)], throwing NotSupportedException with migration guidance. ObsoleteAttribute has no runtime effect, so configuration providers still resolve it by reflection and fail loudly, while code callers get a compile error.

Part of #5245

Why this instead of the IConfiguration parameter

• No new dependency. Sentry.Serilog doesn't take a public dependency on Microsoft.Extensions.Configuration.Abstractions.
• Covers the XML provider too. Serilog.Settings.AppSettings binds sink arguments by parameter name as well, so app.config users are caught. That's the gap noted on the IConfiguration approach, and it matters — Sentry.Serilog targets net462.
• The message has somewhere to go. With the SDK uninitialised there is no DiagnosticLogger, and Serilog's SelfLog is off by default, so a warning would land nowhere. An exception carries its own channel.

What actually happens today

Worth stating plainly, because it's the opposite of what #5573's description currently says: a legacy dsn argument does still bind. Serilog filters candidate methods on the method's parameters being defaulted-or-supplied, not on every supplied name having a parameter, so unmatched arguments are dropped without a word — not even to SelfLog. The sink is attached, Sentry is never initialised, and the app reports nothing.

Verified

scenario	before this PR	after
appsettings.json with dsn	sink binds, dsn silently dropped, no events, no SelfLog output	NotSupportedException at CreateLogger()
app.config with serilog:write-to:Sentry.dsn	same silent drop	NotSupportedException
either, without dsn	works	works, unchanged
WriteTo.Sentry("dsn") in code	CS1503: cannot convert from 'string' to 'LogEventLevel?'	CS0619 carrying the migration message
o.Dsn = "…" in code	CS1061: SentrySerilogOptions does not contain a definition for 'Dsn'	unchanged

67 tests green on net8.0 / net9.0 / net10.0 / net11.0.

Notes for review

• The overload mirrors the surviving overload's parameters plus dsn. That's deliberate. With only string dsn it loses Serilog's overload ranking whenever a configuration supplies two or more of the surviving arguments, which would restore the silent behaviour. Because it's a superset with dsn required, it's selected exactly when dsn is present and never otherwise.
• ApiApprovalTests.Run.Net4_8.verified.txt can't regenerate on macOS. It's a copy of the regenerated DotNet10_0 snapshot, which is the same convention this branch already uses. Worth a Windows CI confirmation.
• No test covers the selection itself. The tests prove the overload throws when invoked by name, which is what a provider does — but proving Serilog.Settings.Configuration picks it needs that package as a test dependency. I didn't add one unilaterally; happy to, it's about 15 lines, and nothing in the repo currently exercises that code path at all.
• The XML path was verified on .NET, not .NET Framework. Serilog.Settings.AppSettings 3.0.0 ships a net8.0 target backed by System.Configuration.ConfigurationManager, so it ran against the real patched assembly on .NET 9. Same binder code, but not literally net462, and that package pulls Serilog 4.0.0 while Sentry.Serilog compiles against 2.10.0.
• It throws. Upgrading with a config-bound DSN becomes a hard startup failure. That seems right for a major — better than discovering three weeks later that nothing has been reported — but it's the reversible part of the design. Swapping the throw for SelfLog.WriteLine and returning the normal sink is a one-line change if you'd rather warn.

Happy to close this if you'd prefer the IConfiguration route.

What the integrator sees

Unhandled exception. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.NotSupportedException: The Sentry sink no longer initializes the SDK, so a DSN can no longer be supplied to it. Initialize Sentry with SentrySdk.Init (or an integration such as UseSentry), call UseSerilog() on those options, and remove 'dsn' and any other core SDK settings from the sink configuration.
   at Serilog.SentrySinkExtensions.Sentry(LoggerSinkConfiguration loggerConfiguration, String dsn, Nullable`1 minimumEventLevel, Nullable`1 minimumBreadcrumbLevel, IFormatProvider formatProvider, ITextFormatter textFormatter, LogEventLevel restrictedToMinimumLevel, LoggingLevelSwitch levelSwitch) in /.../sentry-dotnet/src/Sentry.Serilog/SentrySinkExtensions.cs:line 44
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithManyArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   --- End of inner exception stack trace ---

[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.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 814d3cc. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.70%. Comparing base (3307c30) to head (72d27f9).

Additional details and impacted files

@@                        Coverage Diff                         @@
##           feat/no-init-from-logging-5245    #5611      +/-   ##
==================================================================
- Coverage                           74.71%   74.70%   -0.01%     
==================================================================
  Files                                 515      515              
  Lines                               18826    18811      -15     
  Branches                             3668     3663       -5     
==================================================================
- Hits                                14065    14052      -13     
+ Misses                               3888     3880       -8     
- Partials                              873      879       +6     

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

@ric-oliv yeah I think this is a better approach. Instead of removing all the methods to initialise the SDK from the logging integrations, let's leave them in, mark them obsolete and simply throw from the implementations.

We can definitively remove them in the next major (v8).

I'll domino those changes up the PR stack.