You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Debug.Assert(EventListener.s_EventSources!=null,"should be called within lock on EventListener.EventListenersLock which ensures s_EventSources to be initialized");
if(eventSourceRef.Target is EventSource eventSource && eventSource.Guid == m_guid &&!eventSource.IsDisposed)
2941
+
Debug.Assert(EventListener.s_EventSources!=null,"should be called within lock on EventListener.EventListenersLock which ensures s_EventSources to be initialized");
// This switch controls an opt-in, off-by-default mechanism for allowing multiple EventSources to have the same
3957
+
// name and by extension GUID. This is not considered a mainline scenario and is explicitly intended as a release
3958
+
// valve for users that make heavy use of AssemblyLoadContext and experience exceptions from EventSource.
3959
+
// This does not solve any issues that might arise from this configuration. For instance:
3960
+
//
3961
+
// * If multiple manifest-mode EventSources have the same name/GUID, it is ambiguous which manifest should be used by an ETW parser.
3962
+
// This can result in events being incorrectly parse. The data will still be there, but EventTrace (or other libraries) won't
3963
+
// know how to parse it.
3964
+
// * Potential issues in parsing self-describing EventSources that use the same name/GUID, event name, and payload type from the same AssemblyLoadContext
3965
+
// but have different event IDs set.
3966
+
//
3967
+
// Most users should not turn this on.
3968
+
// see https://github.com/dotnet/runtime/pull/56873 for the upstream changes and conversation
0 commit comments