Skip to content

Support Auto Debug Mode #3212

Open
Open

Description

@vaind

This is the current code:

/// <summary>
/// Whether to log diagnostics messages
/// </summary>
/// <remarks>
/// The verbosity can be controlled through <see cref="DiagnosticLevel"/>
/// and the implementation via <see cref="DiagnosticLogger"/>.
/// </remarks>
public bool Debug
{
get => _debug;
set => _debug = value;
}
/// <summary>
/// The diagnostics level to be used
/// </summary>
/// <remarks>
/// The <see cref="Debug"/> flag has to be switched on for this setting to take effect.
/// </remarks>
public SentryLevel DiagnosticLevel { get; set; } = SentryLevel.Debug;
private volatile IDiagnosticLogger? _diagnosticLogger;
/// <summary>
/// The implementation of the logger.
/// </summary>
/// <remarks>
/// The <see cref="Debug"/> flag has to be switched on for this logger to be used at all.
/// When debugging is turned off, this property is made null and any internal logging results in a no-op.
/// </remarks>
public IDiagnosticLogger? DiagnosticLogger
{
get => Debug ? _diagnosticLogger : null;
set
{
if (value is null)
{
_diagnosticLogger?.LogDebug(
"Sentry will not emit SDK debug messages because debug mode has been turned off.");
}
else
{
_diagnosticLogger?.LogInfo("Replacing current logger with: '{0}'.", value.GetType().Name);
}
_diagnosticLogger = value;
}
}

What this effectively does, AFAICT, is that we don't print any warnings when Debug is not set. That is pretty unexpected behavior, at least to me, especially considering what the docs say when you're setting up sentry:

    // When debug is enabled, the Sentry client will emit detailed debugging information to the console.
    // This might be helpful, or might interfere with the normal operation of your application.
    // We enable it here for demonstration purposes when first trying Sentry.
    // You shouldn't do this in your applications unless you're troubleshooting issues with Sentry.
    options.Debug = true;

Instead, I'd expect the DiagnosticLogger property to always be reachable. It already has a check which log levels should be printed.

Activity

  1. bitsandfoxes commented on Mar 14, 2024

    @bitsandfoxes
    Contributor

    Looks like Debug controls whether the SDK adds its own ConsoleLogger as DiagnosticLogger if none is present.

    internal void SetupLogging()
    {
    if (Debug)
    {
    if (DiagnosticLogger == null)
    {
    DiagnosticLogger = new ConsoleDiagnosticLogger(DiagnosticLevel);
    DiagnosticLogger.LogDebug("Logging enabled with ConsoleDiagnosticLogger and min level: {0}",
    DiagnosticLevel);
    }

    Instead, I'd expect the DiagnosticLogger property to always be reachable. It already has a check which log levels should be printed.

    You can set your own logger and that works independently whether Debug is enabled or not.

  2. vaind commented on Mar 14, 2024

    @vaind
    ContributorAuthor

    Yes you can. Yet again, shouldn't the default at least print warnings and errors, if any occur? As is, it won't print anything unless you set Debug in which case it will print not only warnings but also all the debug messages.

  3. vaind commented on Mar 14, 2024

    @vaind
    ContributorAuthor

    Actually, no, you cannot set a diagnostic logger.

    public IDiagnosticLogger? DiagnosticLogger
    {
    get => Debug ? _diagnosticLogger : null;

    Can we just remove the need to set Debug for DiagnosticLogger to work at all?

  4. bitsandfoxes commented on Apr 11, 2024

    @bitsandfoxes
    Contributor

    Can we just remove the need to set Debug for DiagnosticLogger to work at all?

    As in: If there is a DiagnosticLogger present, log?

  5. vaind commented on Apr 11, 2024

    @vaind
    ContributorAuthor

    Yes, pretty much.

  6. jamescrosswell commented on Apr 12, 2024

    @jamescrosswell
    Collaborator

    We could/should be able to control everything via the DiagnosticLevel right?

    public SentryLevel DiagnosticLevel { get; set; } = SentryLevel.Debug;

    So SentryOptions.Debug is a bit redundant... although lots of customers will definitely know about it so if we do phase it out, probably need to mark it as Obsolete (and keep it as a proxy to setting the DiagnosticLevel) until some time in the distant future (e.g. v5.0).

    Ideally we'd change the default value of SentryOptions.DiagnosticLevel to Warning as well... if people did set Debug = true, that would be (for the time being) an alternative way of setting SentryOptions.DiagnosticLevel = SentryLevel.Debug

  7. vaind commented on Apr 17, 2024

    @vaind
    ContributorAuthor

    So SentryOptions.Debug is a bit redundant... although lots of customers will definitely know about it so if we do phase it out, probably need to mark it as Obsolete (and keep it as a proxy to setting the DiagnosticLevel) until some time in the distant future (e.g. v5.0).

    it is but it's common to all SDKs so I would keep it, just use it to set the diagnostic level to Debug, instead of the default warning - as you're suggesting. The main gripe I have with the current code is the need to enable Debug to get any logs, even warnings

  8. jamescrosswell commented on Apr 18, 2024

    @jamescrosswell
    Collaborator

    The main gripe I have with the current code is the need to enable Debug to get any logs, even warnings

    Yeah fair enough. What do you think should happen if people set SentryOptions.Debug = false though (which is the default value for that property)? Would that set the DiagnosticLevel to Error?

    If we leave SentryOptions.Debug in the SDK, we have to deal with 10 different combinations of those two settings (Debug x DiagnosticLevel) as well as the order that these are set in (if people are using the Options callback) and which one takes precedence (if people are just passing in an options object). Not saying that can't be done but we'd need to decide how it should work first right?

    We could do it a little bit like EnableTracing, which implicitly sets TraceSampleRate to 1.0 or 0.0 depending on whether it's set to true or false. EnableTracing is a bool? though (not a bool). So maybe we could change SentryOptions.Debug to be a bool? and do something similar there? If it's true, we set SentryOptions.DiagnosticLevel to Debug... if it's false we set it to Error... or alternatively people can get more granular by setting SentryOptions.DiagnosticLevel directly. If they've set both though, which one takes precedence?

  9. vaind commented on Apr 18, 2024

    @vaind
    ContributorAuthor

    I've checked what sentry-java and sentry-dart do and they set the default diagnostic logger if debug is true, otherwise leave a noop logger. I think the idea here was the same (since the .net sdk precedes these two, I think) but somehow the part when a user sets their own logger is messed up here. Maybe we should only fix that instead of touching diagnostic levels.

  10. vaind commented on Jan 8, 2025

    @vaind
    ContributorAuthor

    This came up again and there're now develop docs describing how this should be handled.

    https://develop.sentry.dev/sdk/expected-features/#debug-mode

  11. 13 remaining items

  12. vaind commented on Jul 16, 2025

    @vaind
    ContributorAuthor

    however, our default level is DiagnosticLevel = SentryLevel.Debug

    Just to clarify - some SDKs, for the same reason, changed the default log level


    As is, I still believe the SDK should be printing warnings and errors by default. They provide important information and visibility to issues at runtime (for example, not sending any events to Sentry because of misconfiguration)

  13. Flash0ver commented on Jul 16, 2025

    @Flash0ver
    Contributor

    As is, I still believe the SDK should be printing warnings and errors by default. They provide important information and visibility to issues at runtime (for example, not sending any events to Sentry because of misconfiguration)

    Hmmm ... well ... perhaps there is a way we can figure out for this to be helpful, yet not too noisy, as discussed in #4330.

    Is this what you have in mind? (also considering the dev docs)

    • when explicit SentryOptions.Debug = true
      • behavior as is, with DiagnosticLevel = SentryLevel.Debug per default
      • for all Build Configurations
    • when explicit SentryOptions.Debug = false
      • suppress "Auto Debug Mode"
    • when '$(Configuration)'=='DEBUG', and SentryOptions.Debug is not explicitly set
      • use a Diagnostic-Logger with either SentryLevel.Warning or SentryLevel.Error or SentryLevel.Fatal as minimum level
      • detectable via a Source-Generator

    A couple of thoughts:

    • our current Source-Generator approach depends on [ModuleInitializer] and only works for net5.0
      • we would see different "Auto Debug Mode" behavior between .NET Framework and .NET apps (that have not reached End-Of-Support yet)
    • our current Source-Generator only supports C#
      • but we could expand it to also work for Visual Basic projects
      • however, we would need a different solution for F#, as it's not based on the Roslyn Compiler
    • we could instead have a Source-Generator that works with C# Interceptors instead
      • but this requires a .NET 9-compatible version of the Compiler
      • and only works for C#, no support for Visual Basic
      • and again, no F#

    Which leads me to a question:

    • a Source-Generator-based approach would not work for sentry-unity nor sentry-powershell
      • sentry-unity: I guess in Unity we could inject something similar to the consuming game, to detect a Debug-Configuration, couldn't we @bitsandfoxes?
      • sentry-powershell: for PowerShell I have never thought about the difference of a Debug-vs-Release build
        • @vaind is there some facility to detect the consuming script is in a Debug-Configuration/Debug-Mode
        • and is there some facility for the Sentry SDK to detect that and configure the Diagnsotic-Logger accordingly

    TL;DR;
    Questions about behavior between older .NET Target Frameworks and newer .NET Target Frameworks;
    and between C#, VB and F#;
    and between sentry-dotnet, sentry-powershell and sentry-unity.

  14. vaind commented on Jul 16, 2025

    @vaind
    ContributorAuthor

    It is perfectly fine to have things only work for a subset of SDK users, if the subset is reasonably large. I don't know how many VB or F# consumers we have (I am not aware whether we track this) but I'm quite convinced it's safe to assume most would be using c#. If we can improve developer-experience for 90+ % of new users with a reasonable effort, I believe we should do that, but you're the maintainer of the SDK so it's up to you.

  15. added this to the 6.0.0 milestone on Jul 17, 2025
  16. Flash0ver commented on Jul 23, 2025

    @Flash0ver
    Contributor

    @jamescrosswell and I reiterated, and we're thinking about updating a prominent sample, or maybe most/all of the samples, in the docs with

    #if DEBUG
    options.Debug = true;
    #endif
    
  17. removed theissue type on Aug 6, 2025
  18. removed this from the 6.0.0 milestone on Dec 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    .NETPull requests that update .net codeFeatureNew feature or requestLogs

    Projects

    • Status
      Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions