Skip to content

Commit 1c94dae

Browse files
jamescrosswellclaudegetsentry-botric-oliv
authored
feat(nlog)!: the Sentry target no longer initializes the SDK (#5585)
* feat: Serilog sink no longer initializes the SDK The Sentry sink for Serilog now only configures the sink. Sentry must be initialized separately (SentrySdk.Init, UseSentry, etc). - SentrySerilogOptions no longer derives from SentryOptions and only carries sink settings; InitializeSdk is removed - Remove the WriteTo.Sentry(string dsn, ...) overload - Rename ApplySerilogScopeToEvents() to UseSerilog(), make it idempotent - The sink logs a one-time diagnostic warning when UseSerilog() was not called on the options used to initialize Sentry Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Accept API verifier changes * Tweak comments in the samples * feat: NLog target no longer initializes the SDK The Sentry target for NLog now only configures the target. Sentry must be initialized separately (SentrySdk.Init, UseSentry, etc). - SentryNLogOptions no longer derives from SentryOptions and only carries target settings; FlushTimeout moves onto it directly - Remove InitializeSdk, Dsn/DsnLayout, Release/ReleaseLayout, Environment/EnvironmentLayout and ShutdownTimeoutSeconds. Events take release and environment from the SDK options - Collapse the AddSentry overloads into AddSentry(optionsConfig, targetName); the dsn overloads are removed - The target no longer routes SDK diagnostics to NLog's InternalLogger Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Tweaked wording Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com> * feat: NLog target flushes using the SDK's FlushTimeout Remove SentryTarget.FlushTimeoutSeconds and SentryNLogOptions.FlushTimeout. When NLog flushes the target, the hub is now flushed with the FlushTimeout from the options used to initialize Sentry, since the target no longer owns the SDK. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: drop unused Sentry settings from the Serilog sample appsettings The sample sets the DSN in code via UseSentry, so the commented-out Dsn entry is misleading. EnableTracing is declared on BindableSentryOptions but never applied, so setting it has no effect. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(serilog): make the UseSerilog warning check atomic Emit can run concurrently, so the check-then-set on the warned flag could let more than one thread log the warning. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor: the Serilog sink no longer sets the SDK name Sdk.Name should identify the integration that initialised the hub, which after this change can no longer be a logging integration. The sink identifies itself through the log origin (auto.log.serilog) instead. See #5497. Events are no longer stamped with sentry.dotnet.serilog, and structured logs no longer carry it as sentry.sdk.name; both now report the SDK that initialised Sentry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor: the NLog target no longer sets the SDK name Sdk.Name should identify the integration that initialised the hub, which after this change can no longer be a logging integration. The target identifies itself through the log origin (auto.log.nlog) instead. See #5497. Events are no longer stamped with sentry.dotnet.nlog, and structured logs no longer carry it as sentry.sdk.name; both now report the SDK that initialised Sentry. With no remaining callers, Constants is deleted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(serilog): configuring a DSN on the sink now fails with a migration error Serilog configuration providers bind sink arguments by parameter name, so removing the dsn-first overload made them drop `dsn` silently: the sink still binds, Sentry is never initialized, and nothing is reported. Keeping the overload as an [Obsolete(error: true)] tombstone that throws makes both Serilog.Settings.Configuration (appsettings.json) and Serilog.Settings.AppSettings (app.config) fail loudly with migration guidance, while code callers get a compile error instead of a type mismatch on the second argument. The overload mirrors the surviving overload's parameters plus `dsn`. 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. Part of #5245 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(serilog): pin the DSN tombstone against Serilog.Settings.Configuration The migration guard works only because of Serilog's overload ranking, and nothing exercised that path. These tests bind a sink from IConfiguration the way a provider does, so a Serilog change that stops selecting the tombstone fails here rather than silently dropping the DSN again. Verified they fail without the tombstone overload. Selection behaves the same on Serilog.Settings.Configuration 3.4.0 (Serilog 2.12) and 10.0.1 (Serilog 4.3); 3.4.0 is referenced to avoid bumping Serilog in the tests. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(nlog): configuring a DSN on the target now fails with a migration error Mirrors the Serilog guard (#5611). The v6 AddSentry(dsn, ...) overloads and the SentryTarget.Dsn / InitializeSdk properties come back as tombstones: obsolete-as-error for code callers, throwing NotSupportedException so NLog.config bindings fail loudly with migration guidance instead of reporting an unknown property. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(serilog): reword the DSN migration error Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(nlog): reword the DSN migration error to match Serilog Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(serilog): the Sentry sink registers the Serilog scope event processor automatically (#5612) * fix: make the SentryOptions processor collections thread safe SentryClient enumerates these collections lazily for the whole duration of a capture, and AddEventProcessor is documented as supporting registration after the SDK is initialised. They were plain Lists, so appending to one while a capture was in flight threw InvalidOperationException - which the SDK catches and logs at Debug, silently dropping the event. Swap them for ConcurrentBagLite, which snapshots on enumeration. Scope.EventProcessors already uses it for the same reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(serilog): register the Serilog scope event processor automatically The sink no longer initialises the SDK, so integrators have to call UseSerilog() on the options used to initialise Sentry. Forgetting it was only reported as a warning gated behind Debug and DiagnosticLevel, so in practice it was silent. The sink now registers SerilogScopeEventProcessor itself: at construction when Sentry is already initialised, otherwise on the first log event. The sink and the processor live in the same assembly, so no reflection is needed and this stays AOT safe. UseSerilog() is still the better option - it applies from the first event rather than from the first log line - and the warning now says so. Also fixes a feedback loop this exposed. Emit answered a reentrant log event with another diagnostic, which Serilog routed straight back into the sink, each message embedding the last. With DiagnosticLevel at Info that produced 55 MB of logs in 17 seconds and the app stopped serving requests. The SDK-namespace filter that breaks the cycle now runs before the reentrancy check instead of after it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Removed unnecessary comments Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com> * fix(serilog): register the scope event processor atomically Sinks sharing one set of SentryOptions can reach registration concurrently - each sink's guard is per-instance - so the check and the add have to happen under a lock, not as check-then-act. The sink now learns from the result whether it was the one that registered, which is what the warning reports. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor(serilog): use the Lock shim for the registration lock Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: samples are exempt from the no-comments rule Restores the DSN comment dropped from the Serilog sample's appsettings.json, pointing at where this sample actually sets it, and records in AGENTS.md that "prefer no comments" covers the library rather than samples - including their JSON configuration files. Part of #5245 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Apply suggestion from @jamescrosswell * feat(serilog): warn at runtime when the sink drops events because Sentry is not initialized The tombstoned overloads catch everyone who passes a DSN to the sink, but they cannot see the `WriteTo.Sentry(o => ...)` callback that only sets sink options and gets its DSN from SENTRY_DSN or a [Dsn] assembly attribute. On 6.x that overload initialized the SDK itself; now it compiles, nothing calls Init, and the sink drops everything silently. Warn once, on the first event at or above MinimumEventLevel, when the hub is disabled and a DSN can still be found. There is no DiagnosticLogger to write to in that state, so the warning goes to Serilog's SelfLog and to standard error. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(nlog): warn at runtime when the target drops events because Sentry is not initialized Mirrors the Serilog sink: the tombstoned Dsn/InitializeSdk properties cannot see an AddSentry(o => ...) call that only sets target options and gets its DSN from SENTRY_DSN or a [Dsn] assembly attribute, so warn once on the first event at or above MinimumEventLevel when the hub is disabled and a DSN can still be found. The warning goes to NLog's InternalLogger and to standard error. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(nlog): report a stale dsn and accept initializeSdk=false (#5652) * fix(nlog): Report a stale dsn and accept initializeSdk=false Both tombstones could leave an upgraded app worse off than it needed to be. A dsn left in NLog.config was silent with NLog's default settings. NLog swallows the setter's exception unless throwConfigExceptions is on, so the target attached, Sentry was never initialized and nothing was printed. The runtime warning also stayed quiet, because it only looks for a DSN in the environment or an assembly attribute. The Dsn setter now writes the migration message to standard error before it throws. initializeSdk="false" was the recommended v6 setting next to UseSentry, and it already matches the new behavior. With throwConfigExceptions on, it still threw, NLog rejected the whole configuration and the app lost every NLog target. The setter now only throws for true, like the Microsoft.Extensions.Logging tombstone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(nlog): report a stale initializeSdk="true" as well The stale dsn message only came from the Dsn setter, so a config carrying initializeSdk="true" instead was still silent with NLog's default throwConfigExceptions: the setter threw, NLog discarded it, the target attached and nothing was printed. Both setters now go through one report-and-throw helper. Reporting from both setters means a v6 config carrying dsn and initializeSdk="true" together would print the same message twice, so the helper reports at most once per target. A configuration reload builds a new target, and so reports again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io> Co-authored-by: Ricardo Colombo Oliveira <github@ricoliv.com>
1 parent 2f21e3f commit 1c94dae

26 files changed

Lines changed: 442 additions & 703 deletions

‎samples/Sentry.Samples.NLog/NLog.config‎

Lines changed: 1 addition & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -10,11 +10,8 @@
1010
<targets>
1111
<target name="logconsole" xsi:type="ColoredConsole" />
1212

13-
<!-- You can also add a `dsn` property to the following target (with the DSN of your Sentry project):
14-
See Program.cs for the DSN used in the code-only example-->
15-
13+
<!-- This only configures the Sentry target. Sentry itself is initialised in Program.cs -->
1614
<target xsi:type="Sentry" name="sentry"
17-
environment="Development"
1815
includeEventProperties="True"
1916
layout="${message}"
2017
breadcrumbLayout="${message}"
@@ -24,13 +21,6 @@
2421
includeEventPropertiesAsTags="True"
2522
minimumEventLevel="Error">
2623

27-
<!-- Advanced options can be configured here-->
28-
<options
29-
attachStacktrace="true"
30-
sendDefaultPii="true"
31-
shutdownTimeoutSeconds="5"
32-
/>
33-
3424
<!--Optionally add any desired additional Tags that will be sent with every message -->
3525
<tag name="exception" layout="${exception:format=shorttype}" includeEmptyValue="false" />
3626

‎samples/Sentry.Samples.NLog/Program.cs‎

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,18 @@ public static class Program
1212

1313
private static void Main()
1414
{
15+
// Initialise the Sentry SDK
16+
using var _ = SentrySdk.Init(options =>
17+
{
18+
#if !SENTRY_DSN_DEFINED_IN_ENV
19+
// A DSN is required. You can set here in code, or you can set it in the SENTRY_DSN environment variable.
20+
// See https://docs.sentry.io/product/sentry-basics/dsn-explainer/
21+
options.Dsn = SamplesShared.Dsn;
22+
#endif
23+
options.AttachStacktrace = true;
24+
options.SendDefaultPii = true; // Send Personal Identifiable information like the username of the user logged in to the device
25+
});
26+
1527
try
1628
{
1729
// You can configure your logger using a configuration file:
@@ -97,28 +109,18 @@ private static void UsingNLogConfigFile()
97109

98110
private static void UsingCodeConfiguration()
99111
{
100-
// Other overloads exist, for example, configure the SDK with only the DSN or no parameters at all.
112+
// Configure NLog to send logs to Sentry
101113
var config = LogManager.Configuration = new LoggingConfiguration();
102114
_ = config
103115
.AddSentry(options =>
104116
{
105-
#if !SENTRY_DSN_DEFINED_IN_ENV
106-
// A DSN is required. You can set here in code, in the SENTRY_DSN environment variable or in the
107-
// NLog.config file.
108-
// See https://docs.sentry.io/product/sentry-basics/dsn-explainer/
109-
options.Dsn = SamplesShared.Dsn;
110-
#endif
111117
options.Layout = "${message}";
112118
options.BreadcrumbLayout = "${logger}: ${message}"; // Optionally specify a separate format for breadcrumbs
113119

114120
options.MinimumBreadcrumbLevel = LogLevel.Debug; // Debug and higher are stored as breadcrumbs (default is Info)
115-
options.MinimumEventLevel = LogLevel.Error; // Error and higher is sent as event (default is Error)
116-
117-
options.AttachStacktrace = true;
118-
options.SendDefaultPii = true; // Send Personal Identifiable information like the username of the user logged in to the device
121+
options.MinimumEventLevel = LogLevel.Error; // Error and higher are sent as events (default is Error)
119122

120123
options.IncludeEventDataOnBreadcrumbs = true; // Optionally include event properties with breadcrumbs
121-
options.ShutdownTimeoutSeconds = 5;
122124

123125
//Optionally specify user properties via NLog (here using MappedDiagnosticsLogicalContext as an example)
124126
options.User = new SentryNLogUser
@@ -134,8 +136,6 @@ private static void UsingCodeConfiguration()
134136
};
135137

136138
options.AddTag("logger", "${logger}"); // Send the logger name as a tag
137-
138-
// Other configuration
139139
});
140140

141141
config.AddTarget(new DebuggerTarget("debugger"));

‎samples/Sentry.Samples.NLog/README.md‎

Lines changed: 3 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -2,20 +2,17 @@
22

33
This is a simple console application that demonstrates how you can add Sentry to your application using NLog.
44

5-
This project attempts to sample the integration by using code only and also via the configuration file.
6-
In both cases **you need to add your own DSN** so you can see the events sent in your Sentry project.
5+
This project demonstrates configuring Sentry and NLog via code and configuration.
6+
The Sentry target configures NLog to send logs to Sentry. The Sentry SDK itself is initialised via the call to `SentrySdk.Init`
7+
in `Program.cs`, so **you need to add your own DSN** there to see the events sent in your Sentry project.
78

89
You can get your [Sentry DSN at sentry.io](https://sentry.io).
9-
Make sure to add it to both `NLog.config` and `Program.cs` in this directory.
1010

1111
## Configuration of NLog.config
1212
The following options are available for the NLog Sentry Target:
1313

1414
```xml
1515
<target xsi:type="Sentry" name="sentry"
16-
dsn="https://123@sentry.io/456"
17-
environment="${environment:cached=true:ASPNETCORE_ENVIRONMENT}"
18-
release="${assembly-version:cached=true:type=File}"
1916
layout="${message}"
2017
includeEventProperties="True"
2118
includeMdlc="False"
@@ -25,17 +22,9 @@ The following options are available for the NLog Sentry Target:
2522
ignoreEventsWithNoException="False"
2623
includeEventDataOnBreadcrumbs="False"
2724
includeEventPropertiesAsTags="True"
28-
initializeSdk="True"
29-
flushTimeoutSeconds="15"
3025
>
3126
<tag name="exception" layout="${exception:format=shorttype}" includeEmptyValue="false" /><!-- Repeatable SentryEvent Tags -->
3227
<contextproperty name="threadid" layout="${threadid}" includeEmptyValue="true" /> <!-- Repeatable SentryEvent Data -->
33-
<!-- Advanced options can be configured here-->
34-
<options
35-
sendDefaultPii="False"
36-
isEnvironmentUser="True"
37-
attachStacktrace="False"
38-
/>
3928
<!-- Optionally specify user properties via NLog (here using MappedDiagnosticsLogicalContext as an example) -->
4029
<user
4130
id="${mdlc:item=id}"
@@ -48,10 +37,6 @@ The following options are available for the NLog Sentry Target:
4837
</target>
4938
```
5039

51-
* **dsn** - Sentry Data Source Name Address. See also https://sentry.io
52-
* **initializeSdk** - Whether the NLog target should initialize the Sentry SDK (Using Dsn). Default: _True_
53-
* **environment** - Application Environment sent to Sentry
54-
* **release** - Application Release Version sent to Sentry
5540
* **layout** - NLog Layout for rendering SentryEvent message. Default: _${message}_
5641
* **includeEventProperties** - Include LogEvent properties as Data on SentryEvent. Default: _True_
5742
* **includeEventPropertiesAsTags** - Include LogEvent properties as extra Tags on SentryEvent. Default: _False_
@@ -61,17 +46,12 @@ The following options are available for the NLog Sentry Target:
6146
* **minimumEventLevel** - Send NLog LogEvents as SentryEvent when matching severity (or worse). Default: _Error_
6247
* **minimumBreadcrumbLevel** - Send NLog LogEvents as Breadcrumbs when matching severity (or worse). Default: _Info_
6348
* **ignoreEventsWithNoException** - Ignore NLog LogEvents without an exception. Default: _False_
64-
* **flushTimeoutSeconds** - Flush timeout in seconds before aborting flush to Sentry. Default: _15_
6549
* **user**
6650
* **id**
6751
* **username**
6852
* **email**
6953
* **ipAddress**
7054
* **other** - Any arbitrary key-value pairs to be included as properties for a user on every event.
71-
* **options**
72-
* **sendDefaultPii** - Whether to include default Personal Identifiable information (UserName / IP-Address). Default: _False_
73-
* **isEnvironmentUser** - Lookup Environment.User if having enabled **sendDefaultPii**. Default: _True_
74-
* **attachStacktrace** - Whether to send the stack trace of a event captured without an exception. Default: _False_
7555

7656
There is filtering logic in the Sentry Target that is usually handled by NLog Logging Rules and Filters.
7757
Mostly because the same Sentry Target is writing both breadcrumbs and actual SentryEvents.

‎src/Sentry.NLog/ConfigurationExtensions.cs‎

Lines changed: 27 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -12,66 +12,58 @@ public static class ConfigurationExtensions
1212
// Internal for testability
1313
internal const string DefaultTargetName = "sentry";
1414

15+
internal const string ObsoleteDsnOverload =
16+
"The Sentry target no longer initializes the SDK, so a DSN can no longer be supplied to it. " +
17+
"Initialize Sentry with SentrySdk.Init (or UseSentry via one of the integrations), and remove 'dsn', " +
18+
"'initializeSdk' and any other core SDK settings from the target configuration.";
19+
1520
/// <summary>
16-
/// Adds a target for Sentry to the NLog configuration.
21+
/// Not supported. The Sentry target no longer initializes the SDK.
1722
/// </summary>
18-
/// <remarks>
19-
/// If DSN is not set, the SDK will look for an environment variable called SENTRY_DSN. If nothing is
20-
/// found, SDK is disabled.
21-
/// </remarks>
2223
/// <param name="configuration">The NLog configuration.</param>
24+
/// <param name="dsn">No longer supported.</param>
2325
/// <param name="optionsConfig">An optional action for configuring the Sentry target options.</param>
24-
/// <returns>The configuration.</returns>
26+
/// <returns>Never returns.</returns>
27+
/// <exception cref="NotSupportedException">Always.</exception>
28+
[Obsolete(ObsoleteDsnOverload, error: true)]
2529
public static LoggingConfiguration AddSentry(
2630
this LoggingConfiguration configuration,
31+
string? dsn,
2732
Action<SentryNLogOptions>? optionsConfig = null)
28-
{
29-
// Not to throw on code that ignores nullability warnings.
30-
if (configuration.IsNull())
31-
{
32-
return configuration!;
33-
}
34-
35-
return configuration.AddSentry(null, DefaultTargetName, optionsConfig);
36-
}
33+
=> throw new NotSupportedException(ObsoleteDsnOverload);
3734

3835
/// <summary>
39-
/// Adds a target for Sentry to the NLog configuration.
36+
/// Not supported. The Sentry target no longer initializes the SDK.
4037
/// </summary>
4138
/// <param name="configuration">The NLog configuration.</param>
42-
/// <param name="dsn">
43-
/// The sentry DSN. If DSN is not set, the SDK will look for an environment variable called SENTRY_DSN.
44-
/// If nothing is found, SDK is disabled.
45-
/// </param>
39+
/// <param name="dsn">No longer supported.</param>
40+
/// <param name="targetName">The name to give the new target.</param>
4641
/// <param name="optionsConfig">An optional action for configuring the Sentry target options.</param>
47-
/// <returns>The configuration.</returns>
42+
/// <returns>Never returns.</returns>
43+
/// <exception cref="NotSupportedException">Always.</exception>
44+
[Obsolete(ObsoleteDsnOverload, error: true)]
4845
public static LoggingConfiguration AddSentry(
4946
this LoggingConfiguration configuration,
5047
string? dsn,
48+
string targetName,
5149
Action<SentryNLogOptions>? optionsConfig = null)
52-
{
53-
// Not to throw on code that ignores nullability warnings.
54-
if (configuration.IsNull())
55-
{
56-
return configuration!;
57-
}
58-
59-
return configuration.AddSentry(dsn, DefaultTargetName, optionsConfig);
60-
}
50+
=> throw new NotSupportedException(ObsoleteDsnOverload);
6151

6252
/// <summary>
6353
/// Adds a target for Sentry to the NLog configuration.
6454
/// </summary>
55+
/// <remarks>
56+
/// This doesn't initialise Sentry. Initialise Sentry separately, using <c>SentrySdk.Init</c> or another Sentry
57+
/// integration (such as ASP.NET Core or MAUI).
58+
/// </remarks>
6559
/// <param name="configuration">The NLog configuration.</param>
66-
/// <param name="dsn">The sentry DSN.</param>
67-
/// <param name="targetName">The name to give the new target.</param>
6860
/// <param name="optionsConfig">An optional action for configuring the Sentry target options.</param>
61+
/// <param name="targetName">The name to give the new target.</param>
6962
/// <returns>The configuration.</returns>
7063
public static LoggingConfiguration AddSentry(
7164
this LoggingConfiguration configuration,
72-
string? dsn,
73-
string targetName,
74-
Action<SentryNLogOptions>? optionsConfig = null)
65+
Action<SentryNLogOptions>? optionsConfig = null,
66+
string targetName = DefaultTargetName)
7567
{
7668
// Not to throw on code that ignores nullability warnings.
7769
if (configuration.IsNull())
@@ -95,11 +87,6 @@ public static LoggingConfiguration AddSentry(
9587
Layout = "${message}",
9688
};
9789

98-
if (dsn != null && string.IsNullOrWhiteSpace(options.Dsn))
99-
{
100-
options.Dsn = dsn;
101-
}
102-
10390
configuration.AddTarget(targetName, target);
10491

10592
configuration.AddRuleForAllLevels(targetName);

‎src/Sentry.NLog/Constants.cs‎

Lines changed: 0 additions & 12 deletions
This file was deleted.

‎src/Sentry.NLog/NLogDiagnosticLogger.cs‎

Lines changed: 0 additions & 58 deletions
This file was deleted.

‎src/Sentry.NLog/Sentry.NLog.csproj‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,7 @@
2828
<Using Include="Sentry.NLog" />
2929
<Using Include="Sentry.Extensibility" />
3030
<Using Include="Sentry.Infrastructure" />
31+
<Using Include="Sentry.Internal" />
3132
<Using Include="Sentry.Reflection" />
3233
</ItemGroup>
3334

0 commit comments

Comments
 (0)