feat(log4net)!: the Sentry appender no longer initializes the SDK

[jamescrosswell]

The log4net portion of #5245, stacked on #5585 (NLog) and following the same design. The Sentry appender for log4net now only sends log events to Sentry; Sentry has to be initialized separately via SentrySdk.Init, UseSentry, etc.

Part of #5245

Breaking changes

• The appender no longer initializes the SDK on the first append. SentryAppender.Dsn remains as a tombstone — [Obsolete(..., error: true)] with a setter that throws NotSupportedException carrying migration guidance, matching feat(serilog): configuring a DSN on the sink now fails with a migration error #5611 (Serilog) and feat(nlog)!: the Sentry target no longer initializes the SDK #5585 (NLog).
• SentryAppender.Environment is removed. Events and structured logs take the environment from the options used to initialize Sentry.
• SentryAppender no longer overrides OnClose. It only existed to dispose the SDK the appender had initialized, so closing the log4net repository no longer flushes Sentry; disposing the handle from SentrySdk.Init does.
• An appender configured with only appender settings still attaches, and on 6.x it initialized the SDK on first append, taking the DSN from SENTRY_DSN or a [Dsn] assembly attribute. The appender therefore warns at runtime — on the first 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 log4net's LogLog and to standard error, at most once per appender. That matters more here than elsewhere, since log4net swallows the tombstone setter's exception and loads the config anyway. The shared policy lives in Sentry.Internal.UninitializedSdkWarning, added in feat(serilog)!: the Sentry sink no longer initializes the SDK #5573.

Before:

<appender name="SentryAppender" type="Sentry.Log4Net.SentryAppender, Sentry.Log4Net">
  <Dsn value="https://key@sentry.io/1" />
  <Environment value="dev" />
</appender>

After:

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

<appender name="SentryAppender" type="Sentry.Log4Net.SentryAppender, Sentry.Log4Net" />

The tombstone behaves differently here than in Serilog and NLog

log4net cannot be made to fail configuration loading. XmlHierarchyConfigurator.SetParameter catches exceptions thrown while setting a parameter, so the throwing setter does not propagate: the config still loads and the appender is still attached. Verified, rather than assumed:

scenario	before this PR	after
app.config with <Dsn value="…" />	log4net:ERROR … Cannot find Property [Dsn] to set object on [Sentry.Log4Net.SentryAppender], config loads, appender attached	log4net:ERROR Failed to set parameter [Dsn] … NotSupportedException: <migration message>, config loads, appender attached
appender.Dsn = "…" in code	CS1061: SentryAppender does not contain a definition for 'Dsn'	CS0619 carrying the migration message
app.config without <Dsn>	works	works, unchanged

So the gain is a better message on the XML path and a compile error carrying migration guidance on the code path — not the hard startup failure Serilog and NLog get. Both messages go to Console.Error via log4net's internal logging unless quiet mode is on.

If a hard failure matters more than keeping the appender working, the alternative is to record the attempt in the setter and throw from ActivateOptions. ParseAppender catches that too, but it drops the appender entirely, so nothing reaches Sentry at all — worse for anyone who initializes correctly but leaves a stale <Dsn> behind. I went with the setter; say the word if you'd rather have the louder one.

Notes for review

• On a disabled hub the appender now returns immediately. That's the same path the old code took when no Dsn was set.
• The unit test fixture now uses an enabled hub. Previously the substitute hub reported IsEnabled == false, and events were only captured because the mocked init had run.
• Environment gets no tombstone, following feat(nlog)!: the Sentry target no longer initializes the SDK #5585, which tombstoned only the SDK-init settings. It's a one-line addition if you'd rather it carried a message too — log4net reports the removal either way, just less usefully.
• Like NLog, log4net needs no UseLog4Net(): identity and properties are applied by the appender to the events and logs it creates.
• ApiApprovalTests.Run.Net4_8 and DotNet10_0 are copies of the regenerated DotNet11_0 snapshot, which all three matched byte-for-byte beforehand. Net4_8 can't regenerate on macOS, and DotNet10_0 isn't run at all since the test project only targets the latest TFM.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 92.85714% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 74.96%. Comparing base (ae9cdda) to head (af47132).

Files with missing lines	Patch %	Lines
src/Sentry.Log4Net/SentryAppender.cs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@                           Coverage Diff                           @@
##           feat/no-init-from-logging-nlog-5245    #5592      +/-   ##
=======================================================================
- Coverage                                75.00%   74.96%   -0.04%     
=======================================================================
  Files                                      515      515              
  Lines                                    18860    18832      -28     
  Branches                                  3660     3655       -5     
=======================================================================
- Hits                                     14145    14118      -27     
  Misses                                    3855     3855              
+ Partials                                   860      859       -1     

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

This gets handled here now (just a couple of lines up):

sentry-dotnet/src/Sentry.Log4Net/SentryAppender.Structured.cs

Line 20 in 6438db5

log.SetDefaultAttributes(options, scope, Sdk);

[ric-oliv]

This one is not a problem, but the runtime warning prints twice on stderr:

log4net:WARN Sentry: the Sentry appender for log4net dropped a log event because Sentry is not initialized, but a DSN was found in the environment or in an assembly attribute. The appender no longer initializes the SDK: call SentrySdk.Init (or UseSentry via one of the integrations) at startup. See https://docs.sentry.io/platforms/dotnet/guides/log4net/
Sentry: the Sentry appender for log4net dropped a log event because Sentry is not initialized, but a DSN was found in the environment or in an assembly attribute. The appender no longer initializes the SDK: call SentrySdk.Init (or UseSentry via one of the integrations) at startup. See https://docs.sentry.io/platforms/dotnet/guides/log4net/

LogLog.Warn writes to stderr by default, and UninitializedSdkWarning then writes the same message again. I saw both lines with SENTRY_DSN set, on 2.0.15 and 3.4.0. Serilog's SelfLog and NLog's InternalLogger are off by default, so only log4net doubles it. Passing no integration writer here would print it once. Keep both if you want LogLog.LogReceived listeners to get it too.

[ric-oliv]

This new test does not run against log4net v3 (not referenced, and also fails due to a potential null reference).
I've opened #5651 on top of this branch to fix this :)