Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider Debug.Listeners API exposure #40167

Open
mwpowellhtx opened this issue Jul 31, 2019 · 10 comments

Comments

@mwpowellhtx
Copy link

commented Jul 31, 2019

I am staring at a use case right now that I need to listen for System.Diagnostics.Debug.WriteLine messages and a listener would be just what I need to get the job done. Therefore, I strongly suggest reconsidering Debug.Listeners exposure. Absent that we must look at adding unnecessary layers of overhead to our Debug.WriteLine listening efforts when a listener would fit the bill nicely.

@joperezr

This comment has been minimized.

Copy link
Member

commented Aug 1, 2019

@mwpowellhtx

This comment has been minimized.

Copy link
Author

commented Aug 1, 2019

The main issue for me is that I am building on a 3P component which calls Debug.WriteLine, so I really need to measure whether the messages landed through Debug.WriteLine. Listeners are the way to do that. I've got something shimmied in for the time being, but it does not measure anything internal to the 3P, only as far as my API scaffold is concerned, so it is a poor measure, at best, as to whether the 3P received the message, never mind whether Debug.WriteLine was actually invoked.

@terrajobst terrajobst transferred this issue from dotnet/standard Aug 8, 2019

@terrajobst

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

I've moved this to CoreFX, because we first would have to make that change here.

@noahfalk, @jkotas @stephentoub are the reasons to not expose Debug.Listeners still sensible today? As far as I can see, Debug lives in System.Private.CorLib while TraceListener lives in System.Diagnostics.TraceSource. We'd have to move this to CorLib.

@mwpowellhtx

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

I've got a workaround in my library that measures when the API sees a message occur, but this is not a substitute for having a Debug Listener, which I need because the 3P library I am building upon routes messages through Debug.WriteLine. This is what I really need to measure, not not just to mock anything. I want to measure with hard data, an actual message. What that means for internal sensibilities, cannot say, don't care. What I've got now is a poor, surface, substitute for what I think is the long term solution.

@stephentoub

This comment has been minimized.

Copy link
Member

commented Aug 9, 2019

To make sure it's known, Trace.Listeners in .NET Core 3.0 will serve as Debug listeners.

@stephentoub stephentoub added this to the 5.0 milestone Aug 9, 2019

@jkotas

This comment has been minimized.

Copy link
Member

commented Aug 9, 2019

We'd have to move this to CoreLib.

Including its dependency closure. The dependency closure was the reason why we have not done this originally. I guess it may not be as bad as it used to be given that we have moved a ton of other stuff to CoreLib. It just makes the reasoning about layering and treeshake-ability harder.

Trace.Listeners in .NET Core 3.0 will serve as Debug listeners.

Yes, this was fixed 350f100 . Trace.Listeners in .NET Core 3.0 is functionally equivalent to what Debug.Listeners would do.

@mwpowellhtx

This comment has been minimized.

Copy link
Author

commented Aug 9, 2019

@jkotas Would you mind clarifying, are you saying that if we install a listener in the Trace.Listeners, messages routing through Debug.Whatever will be seen there?

@stephentoub

This comment has been minimized.

Copy link
Member

commented Aug 9, 2019

Yes. This:

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        Trace.Listeners.Clear();
        Trace.Listeners.Add(new ConsoleTraceListener());
        Debug.Fail("hello");
        Console.WriteLine("got here");
    }
}

on .NET Core 3.0 outputs:

Fail: hello
got here
@mwpowellhtx

This comment has been minimized.

Copy link
Author

commented Aug 9, 2019

@stephentoub To be clear, we are not talking about monitoring Debug.Fail. But rather, Debug.WriteLine. We do not care about Console.WriteLine for this purpose; our 3P subscription uses Debug.WriteLine, beyond our immediate control, so we want to monitor for that when our wrapper invoked the 3P API.

@stephentoub

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

To be clear, we are not talking about monitoring Debug.Fail. But rather, Debug.WriteLine

Yes, that was just an example. All of these APIs go through the same code paths. The following:

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        Trace.Listeners.Clear();
        Trace.Listeners.Add(new ConsoleTraceListener());
        Debug.WriteLine("hello");
        Console.WriteLine("got here");
    }
}

prints:

hello
got here
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.