Requires a way to handle future additions to Trace.Listeners

[ndrwrbgs]

E.g. if the user's existing code adds a TraceListener for a section of code to log to a file - the suggested answer would be for them to use a MutableTracer directly, but we need to meet them where they are.

Unfortunately, Trace.Listeners does not have a way we can get adds to it - which would mean we'd have to have a an OT sink that writes to the existing Trace.Listeners - but not to any that are currently listening just to send the data to OT!

[ndrwrbgs]

It looks like we could use unique EventIDs for the OT -> Trace bridge, and then let the Trace -> OT bridge ignore those EventIDs, but would need to consider the scenario further before implementing.

[ndrwrbgs]

This would work, but we would need to move from TraceSourceEventHookTracer(TraceSource) to an implementation that sends directly to Trace.

Possibly could use a TraceSource that sends to Trace and a TraceFilter that says to ignore those? Might be too many layers of abstraction - hence the needing to revisit later with fresh eyes

public override void TraceData(TraceEventCache eventCache, string source, TraceEventType eventType, int id, object data)
{
            if (id == 1 || id == 2 || id == 3 || id == 4)
            {
                // This is an event from TraceSourceEventHookTracer - e.g. it's an event from OT -> Trace, and we don't want to send it back to OT
                return;
            }