Runtime: [API Proposal] Debug.Provider property

[maryamariyan]

We would like to provide users with option to:
1) Customize UI Dialog to show during Debug/Trace.Fail, and/or
2) Control output sent to debugger. (The old s_WriteCore and s_ShowDialog delegates in Debug)

API Proposal:

```C#
namespace System.Diagnostics
{
///

/// Enables Debug class with option to customize ShowDialog and Write
///

public partial class DebugProvider
{
public virtual void ShowDialog(string stackTrace, string message, string detailMessage, string errorSource) { }
public virtual void Write(string message) { }
}

public static partial class Debug
{
    // Enables (WPF) user with option to override ShowDialog and Write logic
    public static DebugProvider Provider { get { throw null; } set { } }
    ...
}

}
```

cc: @eerhardt @jkotas @danmosemsft

[jkotas]

This is trying to address https://github.com/dotnet/corefx/issues/3708, correct? The proposal should work through the end-to-end scenario and describe how this would address the problem. Looking at the discussion in https://github.com/dotnet/corefx/issues/3708, I am not sure whether the proposed API works well.

Also, we should include alternative solution that does not involve adding a new public API in this discussion. This was discussed in https://github.com/dotnet/corefx/issues/3708 as well.

customize UI Dialog to show during Debug/Trace.Fail
and/or control output sent to debugger

Note that applications can do this already by overriding the default TraceListener. This API is low-level duplicate. We should be clear on how this will interact with the default TraceListeners and its overrides.

DebugInternal

This is public API proposal. It is best to keep the internal implementation details out (you can briefly mention it in one sentence that there is something similar already). Just focus on what the public surface is going to look like and do, like if you were writing documentation for https://docs.microsoft.com/en-us/ .

[maryamariyan]

Note that applications can do this already by overriding the default TraceListener.

Applications can override default TraceListener and add their derived class to change the behavior of Trace.Fail, not Debug.Fail.

Currently, I believe there is no option for users to override the Debug.Fail behavior. The new Debug.Provider property can be set to change Debug.Fail behavior as we as DefaultTraceListener.Fail behavior. (through overriding ShowDialog and/or Write APIs)

[maryamariyan]

Thanks for the feedback. I'll reword this issue to put focus on the end-to-end scenario.

[jkotas]

Applications can override default TraceListener and add their derived class to change the behavior of Trace.Fail, not Debug.Fail.

Debug.Fail too. Try this on desktop - it overrides what happens for Debug.Fail:

using System;
using System.Diagnostics;

class MyTraceLister : TraceListener
{
    public override void Write(string message)
    {
        Console.Write("MyTraceListener: " + message);
    }

    public override void WriteLine(string message)
    {
        Console.WriteLine("MyTraceListener: " + message);
    }
}

class Program
{
    static void Main(string[] args)
    {
        Trace.Listeners.RemoveAt(0);
        Trace.Listeners.Add(new MyTraceLister());
        Debug.Fail("Hello");
    }
}

[maryamariyan]

That's on Desktop though. On .NET Core we don't have the Debug.Listeners API. My comment was purely on current .NET Core behavior.

[maryamariyan]

That said, I see your point. Now that Trace.Listeners is shared with Debug we could expect a similar behavior flow in .NET Core.
I'll need some time to go revisit this API proposal.

[jkotas]

That's on Desktop though. On .NET Core we don't have the Debug.Listeners API. My comment was purely on current .NET Core behavior.

I mean to use Trace.Listeners in my example (updated). It is both in Desktop and .NET Core, and it should work the same way in both after the fixes you have in flight go in.

[maryamariyan]

@jkotas, Yes, my intention for opening this API proposal was to address dotnet/runtime#15386.
Looking back at your example now, seems like if .NET Core could use Trace Listeners to override Debug.Fail, then we would have no reason then to add the above suggested new APIs.

In order to make your example work, all we need is to add a Fail API to DebugProvider and override it in TraceInternal.
This way we can just use Trace Listeners to override Debug.Fail:

• https://github.com/dotnet/corefx/commit/e8a4a24796f8a42dd6089df479b46ffc746784b8
• https://github.com/dotnet/coreclr/commit/58ed3f3b702eec33390e33df95ce8b22995bbb45

Closing this issue because using this approach would only require internal use of DebugProvider in System.Diagnostics.TraceSource.