diff --git a/docs/fundamentals/runtime-libraries/system-diagnostics-tracing-eventsource.md b/docs/fundamentals/runtime-libraries/system-diagnostics-tracing-eventsource.md index 25c3273c302eb..f4ad9cbd73c41 100644 --- a/docs/fundamentals/runtime-libraries/system-diagnostics-tracing-eventsource.md +++ b/docs/fundamentals/runtime-libraries/system-diagnostics-tracing-eventsource.md @@ -35,7 +35,7 @@ Historically, these two formats are derived from two formats that Event Tracing The default event format is , which is set if not specified on . Manifest-based objects generate an XML document representing the events defined on the class upon initialization. This requires the to reflect over itself to generate the provider and event metadata. -To use self-describing (tracelogging) event format, construct your using the constructor, the constructor, or by setting the `EtwSelfDescribingEventFormat` flag on . Self-describing sources generate minimal provider metadata on initialization and only generate event metadata when is called. +To use self-describing (tracelogging) event format, construct your using the constructor, the constructor, or by setting the `EtwSelfDescribingEventFormat` flag on . Self-describing sources generate minimal provider metadata on initialization and only generate event metadata when is called. Unlike the manifest-based format, when listening via ETW only the Level, Keyword, and Opcode metadata are included from the attribute. Other properties such as EventId or Message are not included. In practice, these event format settings only affect usage with readers based on Event Tracing for Windows (ETW). They can, however, have a small effect on initialization time and per-event write times due to the time required for reflection and generating the metadata.