<?xml version="1.0"?>
<doc>
    <assembly>
        <name>System.Diagnostics.DiagnosticSource</name>
    </assembly>
    <members>
        <member name="T:System.Diagnostics.DiagnosticSource">
            <summary>
            This is the basic API to 'hook' parts of the framework.   It is like an EventSource
            (which can also write object), but is intended to log complex objects that can't be serialized.
            
            Please See the DiagnosticSource Users Guide 
            https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md
            for instructions on its use.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSource.Write(System.String,System.Object)">
            <summary>
            Write is a generic way of logging complex payloads.  Each notification
            is given a name, which identifies it as well as a object (typically an anonymous type)
            that gives the information to pass to the notification, which is arbitrary.  
            
            The name should be short (so don't use fully qualified names unless you have to
            to avoid ambiguity), but you want the name to be globally unique.  Typically your componentName.eventName
            where componentName and eventName are strings less than 10 characters are a good compromise.  
            notification names should NOT have '.' in them because component names have dots and for them both
            to have dots would lead to ambiguity.   The suggestion is to use _ instead.  It is assumed 
            that listeners will use string prefixing to filter groups, thus having hierarchy in component 
            names is good.  
            </summary>
            <param name="name">The name of the event being written.</param>
            <param name="value">An object that represent the value being passed as a payload for the event.
            This is often a anonymous type which contains several sub-values.</param>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSource.IsEnabled(System.String)">
            <summary>
            Optional: if there is expensive setup for the notification, you can call IsEnabled
            before doing this setup.   Consumers should not be assuming that they only get notifications
            for which IsEnabled is true however, it is optional for producers to call this API. 
            The name should be the same as what is passed to Write.   
            </summary>
            <param name="name">The name of the event being written.</param>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSource.IsEnabled(System.String,System.Object,System.Object)">
            <summary>
            Optional: if there is expensive setup for the notification, you can call IsEnabled
            before doing this setup with context 
            </summary>
            <param name="name">The name of the event being written.</param>
            <param name="arg1">An object that represents the additional context for IsEnabled.
            Consumers should expect to receive null which may indicate that producer called pure 
            IsEnabled(string)  to check if consumer wants to get notifications for such events at all. 
            Based on it, producer may call IsEnabled(string, object, object) again with non-null context </param>
            <param name="arg2">Optional. An object that represents the additional context for IsEnabled. 
            Null by default. Consumers shoud expect to receive null which may indicate that producer 
            called pure IsEnabled(string) or producer passed all necessary context in arg1</param>
            <seealso cref="M:System.Diagnostics.DiagnosticSource.IsEnabled(System.String)"/>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSource.StartActivity(System.Diagnostics.Activity,System.Object)">
            <summary>
            Starts an Activity and writes start event.
            
            Activity describes logical operation, its context and parent relation; 
            Current activity flows through the operation processing.
            
            This method starts given Activity (maintains global Current Activity 
            and Parent for the given activity) and notifies consumers  that new Activity 
            was started. Consumers could access <see cref="P:System.Diagnostics.Activity.Current"/>
            to add context and/or augment telemetry.
            
            Producers may pass additional details to the consumer in the payload.
            </summary>
            <param name="activity">Activity to be started</param>
            <param name="args">An object that represent the value being passed as a payload for the event.</param>
            <returns>Started Activity for convenient chaining</returns>
            <seealso cref="T:System.Diagnostics.Activity"/>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSource.StopActivity(System.Diagnostics.Activity,System.Object)">
            <summary>
            Stops given Activity: maintains global Current Activity and notifies consumers 
            that Activity was stopped. Consumers could access <see cref="P:System.Diagnostics.Activity.Current"/>
            to add context and/or augment telemetry.
            
            Producers may pass additional details to the consumer in the payload.
            </summary>
            <param name="activity">Activity to be stopped</param>
            <param name="args">An object that represent the value being passed as a payload for the event.</param>
            <seealso cref="T:System.Diagnostics.Activity"/>
        </member>
        <member name="T:System.Diagnostics.DiagnosticListener">
            <summary>
            A DiagnosticListener is something that forwards on events written with DiagnosticSource.
            It is an IObservable (has Subscribe method), and it also has a Subscribe overloads that
            lets you specify a 'IsEnabled' predicate that users of DiagnosticSource will use for 
            'quick checks'.   
            
            The item in the stream is a KeyValuePair[string, object] where the string is the name
            of the diagnostic item and the object is the payload (typically an anonymous type).  
            
            There may be many DiagnosticListeners in the system, but we encourage the use of
            The DiagnosticSource.DefaultSource which goes to the DiagnosticListener.DefaultListener.
            
            If you need to see 'everything' you can subscribe to the 'AllListeners' event that
            will fire for every live DiagnosticListener in the appdomain (past or present). 
            
            Please See the DiagnosticSource Users Guide 
            https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md
            for instructions on its use.  
            </summary>
        </member>
        <member name="P:System.Diagnostics.DiagnosticListener.AllListeners">
            <summary>
            When you subscribe to this you get callbacks for all NotificationListeners in the appdomain
            as well as those that occurred in the past, and all future Listeners created in the future. 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.Subscribe(System.IObserver{System.Collections.Generic.KeyValuePair{System.String,System.Object}},System.Predicate{System.String})">
            <summary>
            Add a subscriber (Observer).  If 'IsEnabled' == null (or not present), then the Source's IsEnabled 
            will always return true.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.Subscribe(System.IObserver{System.Collections.Generic.KeyValuePair{System.String,System.Object}},System.Func{System.String,System.Object,System.Object,System.Boolean})">
            <summary>
            Add a subscriber (Observer).  If 'IsEnabled' == null (or not present), then the Source's IsEnabled 
            will always return true.  
            </summary>
            <param name="observer">Subscriber (IObserver)</param>
            <param name="isEnabled">Filters events based on their name (string) and context objects that could be null.
            Note that producer may first call filter with event name only and null context arguments and filter should
            return true if consumer is interested in any of such events. Producers that support 
            context-based filtering will invoke isEnabled again with context for more prcise filtering.
            Use Subscribe overload with name-based filtering if producer does NOT support context-based filtering</param>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.Subscribe(System.IObserver{System.Collections.Generic.KeyValuePair{System.String,System.Object}})">
            <summary>
            Same as other Subscribe overload where the predicate is assumed to always return true.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.#ctor(System.String)">
            <summary>
            Make a new DiagnosticListener, it is a NotificationSource, which means the returned result can be used to 
            log notifications, but it also has a Subscribe method so notifications can be forwarded
            arbitrarily.  Thus its job is to forward things from the producer to all the listeners
            (multi-casting).    Generally you should not be making your own DiagnosticListener but use the
            DiagnosticListener.Default, so that notifications are as 'public' as possible.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.Dispose">
            <summary>
            Clean up the NotificationListeners.   Notification listeners do NOT DIE ON THEIR OWN
            because they are in a global list (for discoverability).  You must dispose them explicitly. 
            Note that we do not do the Dispose(bool) pattern because we frankly don't want to support
            subclasses that have non-managed state.   
            </summary>
        </member>
        <member name="P:System.Diagnostics.DiagnosticListener.Name">
            <summary>
            When a DiagnosticListener is created it is given a name.   Return this.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.ToString">
            <summary>
            Return the name for the ToString() to aid in debugging.  
            </summary>
            <returns></returns>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.IsEnabled">
            <summary>
            Determines whether there are any registered subscribers
            </summary>
            <remarks> If there is an expensive setup for the notification,
            you may call IsEnabled() as the first and most efficient check before doing this setup. 
            Producers may optionally use this check before IsEnabled(string) in the most performance-critical parts of the system
            to ensure somebody listens to the DiagnosticListener at all.</remarks>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.IsEnabled(System.String)">
            <summary>
            Override abstract method
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.IsEnabled(System.String,System.Object,System.Object)">
            <summary>
            Override abstract method
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.Write(System.String,System.Object)">
            <summary>
            Override abstract method
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticListener.AllListenerObservable">
            <summary>
            Logically AllListenerObservable has a very simple task.  It has a linked list of subscribers that want
            a callback when a new listener gets created.   When a new DiagnosticListener gets created it should call 
            OnNewDiagnosticListener so that AllListenerObservable can forward it on to all the subscribers.   
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.AllListenerObservable.OnNewDiagnosticListener(System.Diagnostics.DiagnosticListener)">
            <summary>
            Called when a new DiagnosticListener gets created to tell anyone who subscribed that this happened.  
            </summary>
            <param name="diagnosticListener"></param>
        </member>
        <member name="M:System.Diagnostics.DiagnosticListener.AllListenerObservable.Remove(System.Diagnostics.DiagnosticListener.AllListenerObservable.AllListenerSubscription)">
            <summary>
            Remove 'subscription from the list of subscriptions that the observable has.   Called when
            subscriptions are disposed.   Returns true if the subscription was removed.  
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticListener.AllListenerObservable.AllListenerSubscription">
            <summary>
            One node in the linked list of subscriptions that AllListenerObservable keeps.   It is
            IDisposable, and when that is called it removes itself from the list.  
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticSourceEventSource">
            <summary>
            DiagnosticSourceEventSource serves two purposes 
            
              1) It allows debuggers to inject code via Function evaluation.  This is the purpose of the
              BreakPointWithDebuggerFuncEval function in the 'OnEventCommand' method.   Basically even in
              release code, debuggers can place a breakpoint in this method and then trigger the
              DiagnosticSourceEventSource via ETW.  Thus from outside the process you can get a hook that
              is guaranteed to happen BEFORE any DiangosticSource events (if the process is just starting)
              or as soon as possible afterward if it is on attach.
              
              2) It provides a 'bridge' that allows DiagnosticSource messages to be forwarded to EventListers
              or ETW.    You can do this by enabling the Microsoft-Diagnostics-DiagnosticSource with the
              'Events' keyword (for diagnostics purposes, you should also turn on the 'Messages' keyword.  
              
              This EventSource defines a EventSource argument called 'FilterAndPayloadSpecs' that defines
              what DiagnsoticSources to enable and what parts of the payload to serialize into the key-value
              list that will be forwarded to the EventSource.    If it is empty, values of properties of the 
              diagnostic source payload are dumped as strings (using ToString()) and forwarded to the EventSource.  
              For what people think of as serializable object strings, primitives this gives you want you want. 
              (the value of the property in string form) for what people think of as non-serialiable objects 
              (e.g. HttpContext) the ToString() method is typically not defined, so you get the Object.ToString() 
              implemenation that prints the type name.  This is useful since this is the information you need 
              (the type of the property) to discover the field names so you can create a transform specification
              that will pick off the properties you desire.  
              
              Once you have the particular values you desire, the implicit payload elements are typically not needed
              anymore and you can prefix the Transform specification with a '-' which suppresses the implicit 
              transform (you only get the values of the properties you specifically ask for.  
            
              Logically a transform specification is simply a fetching specification X.Y.Z along with a name to give
              it in the output (which defaults to the last name in the fetch specification).  
            
              The FilterAndPayloadSpecs is one long string with the following structures
              
              * It is a newline separated list of FILTER_AND_PAYLOAD_SPEC
              * a FILTER_AND_PAYLOAD_SPEC can be 
                  * EVENT_NAME : TRANSFORM_SPECS
                  * EMPTY - turns on all sources with implicit payload elements. 
              * an EVENTNAME can be  
                  * DIAGNOSTIC_SOURCE_NAME / DIAGNOSTC_EVENT_NAME @ EVENT_SOURCE_EVENTNAME  - give the name as well as the EventSource event to log it under.  
                  * DIAGNOSTIC_SOURCE_NAME / DIAGNOSTC_EVENT_NAME   
                  * DIAGNOSTIC_SOURCE_NAME    - which wildcards every event in the Diagnostic source or 
                  * EMPTY                     - which turns on all sources
              * TRANSFORM_SPEC is a semicolon separated list of TRANSFORM_SPEC, which can be 
                  * - TRANSFORM_SPEC               - the '-' indicates that implicit payload elements should be suppressed 
                  * VARIABLE_NAME = PROPERTY_SPEC  - indicates that a payload element 'VARIABLE_NAME' is created from PROPERTY_SPEC
                  * PROPERTY_SPEC                  - This is a shortcut where VARIABLE_NAME is the LAST property name
              * a PROPERTY_SPEC is basically a list of names separated by '.'  
                  * PROPERTY_NAME                  - fetches a property from the DiagnosticSource payload object
                  * PROPERTY_NAME . PROPERTY NAME  - fetches a sub-property of the object. 
            
            Example1:
            
               "BridgeTestSource1/TestEvent1:cls_Point_X=cls.Point.X;cls_Point_Y=cls.Point.Y\r\n" + 
               "BridgeTestSource2/TestEvent2:-cls.Url"
              
            This indicates that two events should be turned on, The 'TestEvent1' event in BridgeTestSource1 and the
            'TestEvent2' in BridgeTestSource2.   In the first case, because the transform did not begin with a - 
            any primitive type/string of 'TestEvent1's payload will be serialized into the output.  In addition if
            there a property of the payload object called 'cls' which in turn has a property 'Point' which in turn
            has a property 'X' then that data is also put in the output with the name cls_Point_X.   Similarly 
            if cls.Point.Y exists, then that value will also be put in the output with the name cls_Point_Y.
            
            For the 'BridgeTestSource2/TestEvent2' event, because the - was specified NO implicit fields will be 
            generated, but if there is a property call 'cls' which has a property 'Url' then that will be placed in
            the output with the name 'Url' (since that was the last property name used and no Variable= clause was 
            specified. 
            
            Example:
            
                "BridgeTestSource1\r\n" + 
                "BridgeTestSource2"
                
            This will enable all events for the BridgeTestSource1 and BridgeTestSource2 sources.   Any string/primitive 
            properties of any of the events will be serialized into the output.  
            
            Example:
            
                ""
                
            This turns on all DiagnosticSources Any string/primitive properties of any of the events will be serialized 
            into the output.   This is not likely to be a good idea as it will be very verbose, but is useful to quickly
            discover what is available.
            
            
            * How data is logged in the EventSource 
            
            By default all data from DiagnosticSources is logged to the DiagnosticEventSouce event called 'Event' 
            which has three fields  
            
                string SourceName, 
                string EventName, 
                IEnumerable[KeyValuePair[string, string]] Argument
            
            However to support start-stop activity tracking, there are six other events that can be used 
            
                Activity1Start         
                Activity1Stop
                Activity2Start
                Activity2Stop
                RecursiveActivity1Start
                RecursiveActivity1Stop
                
            By using the SourceName/EventName@EventSourceName syntax, you can force particular DiagnosticSource events to
            be logged with one of these EventSource events.   This is useful because the events above have start-stop semantics
            which means that they create activity IDs that are attached to all logging messages between the start and
            the stop (see https://blogs.msdn.microsoft.com/vancem/2015/09/14/exploring-eventsource-activity-correlation-and-causation-features/)
            
            For example the specification 
                
                "MyDiagnosticSource/RequestStart@Activity1Start\r\n" + 
                "MyDiagnosticSource/RequestStop@Activity1Stop\r\n" + 
                "MyDiagnosticSource/SecurityStart@Activity2Start\r\n" + 
                "MyDiagnosticSource/SecurityStop@Activity2Stop\r\n" 
            
            Defines that RequestStart will be logged with the EventSource Event Activity1Start (and the cooresponding stop) which
            means that all events caused between these two markers will have an activity ID assocatied with this start event.  
            Simmilarly SecurityStart is mapped to Activity2Start.    
            
            Note you can map many DiangosticSource events to the same EventSource Event (e.g. Activity1Start).  As long as the
            activities don't nest, you can reuse the same event name (since the payloads have the DiagnosticSource name which can
            disambiguate).   However if they nest you need to use another EventSource event because the rules of EventSource 
            activities state that a start of the same event terminates any existing activity of the same name.   
            
            As its name suggests RecursiveActivity1Start, is marked as recursive and thus can be used when the activity can nest with 
            itself.   This should not be a 'top most' activity because it is not 'self healing' (if you miss a stop, then the
            activity NEVER ends).   
            
            See the DiagnosticSourceEventSourceBridgeTest.cs for more explicit examples of using this bridge.  
            </summary>
        </member>
        <member name="F:System.Diagnostics.DiagnosticSourceEventSource.Keywords.Messages">
            <summary>
            Indicates diagnostics messages from DiagnosticSourceEventSource should be included. 
            </summary>
        </member>
        <member name="F:System.Diagnostics.DiagnosticSourceEventSource.Keywords.Events">
            <summary>
            Indicates that all events from all diagnostic sources should be forwarded to the EventSource using the 'Event' event.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.Message(System.String)">
            <summary>
            Used to send ad-hoc diagnostics to humans.   
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.Event(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Events from DiagnosticSource can be forwarded to EventSource using this event.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.EventJson(System.String,System.String,System.String)">
            <summary>
            This is only used on V4.5 systems that don't have the ability to log KeyValuePairs directly.
            It will eventually go away, but we should always reserve the ID for this.    
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.Activity1Start(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Used to mark the beginning of an activity 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.Activity1Stop(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Used to mark the end of an activity 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.Activity2Start(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Used to mark the beginning of an activity 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.Activity2Stop(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Used to mark the end of an activity that can be recursive.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.RecursiveActivity1Start(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Used to mark the beginning of an activity 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.RecursiveActivity1Stop(System.String,System.String,System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
            <summary>
            Used to mark the end of an activity that can be recursive.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.NewDiagnosticListener(System.String)">
            <summary>
            Fires when a new DiagnosticSource becomes available.   
            </summary>
            <param name="SourceName"></param>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.#ctor">
            <summary>
            This constructor uses EventSourceSettings which is only available on V4.6 and above
            systems.   We use the EventSourceSettings to turn on support for complex types. 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.OnEventCommand(System.Diagnostics.Tracing.EventCommandEventArgs)">
            <summary>
            Called when the EventSource gets a command from a EventListener or ETW. 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.BreakPointWithDebuggerFuncEval">
            <summary>
            A function which is fully interruptible even in release code so we can stop here and 
            do function evaluation in the debugger.   Thus this is just a place that is useful
            for the debugger to place a breakpoint where it can inject code with function evaluation
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform">
            <summary>
            FilterAndTransform represents on transformation specification from a DiagnosticsSource
            to EventSource's 'Event' method.    (e.g.  MySource/MyEvent:out=prop1.prop2.prop3).
            Its main method is 'Morph' which takes a DiagnosticSource object and morphs it into
            a list of string,string key value pairs.   
            
            This method also contains that static 'Create/Destroy FilterAndTransformList, which
            simply parse a series of transformation specifications.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.CreateFilterAndTransformList(System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform@,System.String,System.Diagnostics.DiagnosticSourceEventSource)">
            <summary>
            Parses filterAndPayloadSpecs which is a list of lines each of which has the from
            
               DiagnosticSourceName/EventName:PAYLOAD_SPEC
               
            where PAYLOADSPEC is a semicolon separated list of specifications of the form
            
               OutputName=Prop1.Prop2.PropN
               
            Into linked list of FilterAndTransform that together forward events from the given
            DiagnosticSource's to 'eventSource'.   Sets the 'specList' variable to this value
            (destroying anything that was there previously).  
            
            By default any serializable properties of the payload object are also included
            in the output payload, however this feature and be tuned off by prefixing the
            PAYLOADSPEC with a '-'.   
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.DestroyFilterAndTransformList(System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform@)">
            <summary>
            This destroys (turns off) the FilterAndTransform stopping the forwarding started with CreateFilterAndTransformList
            </summary>
            <param name="specList"></param>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.#ctor(System.String,System.Int32,System.Int32,System.Diagnostics.DiagnosticSourceEventSource,System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform)">
            <summary>
            Creates one FilterAndTransform specification from filterAndPayloadSpec starting at 'startIdx' and ending just before 'endIdx'. 
            This FilterAndTransform will subscribe to DiagnosticSources specified by the specification and forward them to 'eventSource.
            For convenience, the 'Next' field is set to the 'next' parameter, so you can easily form linked lists.  
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec">
            <summary>
            Transform spec represents a string that describes how to extract a piece of data from
            the DiagnosticSource payload.   An example string is OUTSTR=EVENT_VALUE.PROP1.PROP2.PROP3
            It has a Next field so they can be chained together in a linked list.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.#ctor(System.String,System.Int32,System.Int32,System.Diagnostics.DiagnosticSourceEventSource.TransformSpec)">
            <summary>
            parse the strings 'spec' from startIdx to endIdx (points just beyond the last considered char)
            The syntax is ID1=ID2.ID3.ID4 ....   Where ID1= is optional.    
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.Morph(System.Object)">
            <summary>
            Given the DiagnosticSourcePayload 'obj', compute a key-value pair from it.  For example 
            if the spec is OUTSTR=EVENT_VALUE.PROP1.PROP2.PROP3 and the ultimate value of PROP3 is
            10 then the return key value pair is  KeyValuePair("OUTSTR","10") 
            </summary>
        </member>
        <member name="F:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.Next">
            <summary>
            A public field that can be used to form a linked list.   
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec">
            <summary>
            A PropertySpec represents information needed to fetch a property from 
            and efficiently.   Thus it represents a '.PROP' in a TransformSpec
            (and a transformSpec has a list of these).  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.#ctor(System.String,System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec)">
            <summary>
            Make a new PropertySpec for a property named 'propertyName'. 
            For convenience you can set he 'next' field to form a linked
            list of PropertySpecs. 
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.Fetch(System.Object)">
            <summary>
            Given an object fetch the property that this PropertySpec represents.  
            </summary>
        </member>
        <member name="F:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.Next">
            <summary>
            A public field that can be used to form a linked list.   
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.PropertyFetch">
            <summary>
            PropertyFetch is a helper class.  It takes a PropertyInfo and then knows how
            to efficiently fetch that property from a .NET object (See Fetch method).  
            It hides some slightly complex generic code.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.PropertyFetch.FetcherForProperty(System.Reflection.PropertyInfo)">
            <summary>
            Create a property fetcher from a .NET Reflection PropertyInfo class that
            represents a property of a particular type.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.PropertyFetch.Fetch(System.Object)">
            <summary>
            Given an object, fetch the property that this propertyFech represents. 
            </summary>
        </member>
        <member name="T:System.Diagnostics.DiagnosticSourceEventSource.CallbackObserver`1">
            <summary>
            CallbackObserver is a adapter class that creates an observer (which you can pass
            to IObservable.Subscribe), and calls the given callback every time the 'next' 
            operation on the IObserver happens. 
            </summary>
            <typeparam name="T"></typeparam>
        </member>
        <member name="T:System.Diagnostics.Activity">
            <summary>
            Activity represents operation with context to be used for logging.
            Activity has operation name, Id, start time and duration, tags and baggage.
             
            Current activity can be accessed with static AsyncLocal variable Activity.Current.
            
            Activities should be created with constructor, configured as necessary
            and then started with Activity.Start method which maintains parent-child
            relationships for the activities and sets Activity.Current.
            
            When activity is finished, it should be stopped with static Activity.Stop method.
            
            No methods on Activity allow exceptions to escape as a response to bad inputs.
            They are thrown and caught (that allows Debuggers and Monitors to see the error)
            but the exception is supressed, and the operation does something reasonable (typically
            doing nothing).  
            </summary>
        </member>
        <member name="P:System.Diagnostics.Activity.OperationName">
            <summary>
            An operation name is a COARSEST name that is useful grouping/filtering. 
            The name is typically a compile-time constant.   Names of Rest APIs are
            reasonable, but arguments (e.g. specific accounts etc), should not be in
            the name but rather in the tags.  
            </summary>
        </member>
        <member name="P:System.Diagnostics.Activity.Id">
            <summary>
            This is an ID that is specific to a particular request.   Filtering
            to a particular ID insures that you get only one request that matches.  
            Id has a hierarchical structure: '|root-id.id1_id2.id3_' Id is generated when 
            <see cref="M:System.Diagnostics.Activity.Start"/> is called by appending suffix to Parent.Id
            or ParentId; Activity has no Id until it started
            <para/>
            See <see href="https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md#id-format"/> for more details
            </summary>
            <example>
            Id looks like '|a000b421-5d183ab6-Server1.1.8e2d4c28_1.':<para />
             - '|a000b421-5d183ab6-Server1.' - Id of the first, top-most, Activity created<para />
             - '|a000b421-5d183ab6-Server1.1.' - Id of a child activity. It was started in the same process as the first activity and ends with '.'<para />
             - '|a000b421-5d183ab6-Server1.1.8e2d4c28_' - Id of the grand child activity. It was started in another process and ends with '_'<para />
            'a000b421-5d183ab6-Server1' is a <see cref="P:System.Diagnostics.Activity.RootId"/> for the first Activity and all its children
            </example>
        </member>
        <member name="P:System.Diagnostics.Activity.StartTimeUtc">
            <summary>
            The time that operation started.  It will typically be initialized when <see cref="M:System.Diagnostics.Activity.Start"/>
            is called, but you can set at any time via <see cref="M:System.Diagnostics.Activity.SetStartTime(System.DateTime)"/>.
            </summary>
        </member>
        <member name="P:System.Diagnostics.Activity.Parent">
            <summary>
            If the Activity that created this activity is from the same process you can get 
            that Activity with Parent.  However, this can be null if the Activity has no
            parent (a root activity) or if the Parent is from outside the process.
            </summary>
            <seealso cref="P:System.Diagnostics.Activity.ParentId"/>
        </member>
        <member name="P:System.Diagnostics.Activity.ParentId">
            <summary>
            If the parent for this activity comes from outside the process, the activity
            does not have a Parent Activity but MAY have a ParentId (which was deserialized from
            from the parent).   This accessor fetches the parent ID if it exists at all.  
            Note this can be null if this is a root Activity (it has no parent)
            <para/>
            See <see href="https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md#id-format"/> for more details
            </summary>
        </member>
        <member name="P:System.Diagnostics.Activity.RootId">
            <summary>
            Root Id is substring from Activity.Id (or ParentId) between '|' (or beginning) and first '.'.
            Filtering by root Id allows to find all Activities involved in operation processing.
            RootId may be null if Activity has neither ParentId nor Id.
            See <see href="https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md#id-format"/> for more details
            </summary>
        </member>
        <member name="P:System.Diagnostics.Activity.Tags">
            <summary>
            Tags are string-string key-value pairs that represent information that will
            be logged along with the Activity to the logging system.   This information
            however is NOT passed on to the children of this activity.
            </summary>
            <seealso cref="P:System.Diagnostics.Activity.Baggage"/>
        </member>
        <member name="P:System.Diagnostics.Activity.Baggage">
            <summary>
            Baggage is string-string key-value pairs that represent information that will
            be passed along to children of this activity.   Baggage is serialized 
            when requests leave the process (along with the ID).   Typically Baggage is
            used to do fine-grained control over logging of the activity and any children.  
            In general, if you are not using the data at runtime, you should be using Tags 
            instead. 
            </summary> 
        </member>
        <member name="M:System.Diagnostics.Activity.GetBaggageItem(System.String)">
            <summary>
            Returns the value of the key-value pair added to the activity with <see cref="M:System.Diagnostics.Activity.AddBaggage(System.String,System.String)"/>.
            Returns null if that key does not exist.  
            </summary>
        </member>
        <member name="M:System.Diagnostics.Activity.#ctor(System.String)">
            <summary>
            Note that Activity has a 'builder' pattern, where you call the constructor, a number of 'Set*' and 'Add*' APIs and then
            call <see cref="M:System.Diagnostics.Activity.Start"/> to build the activity.  You MUST call <see cref="M:System.Diagnostics.Activity.Start"/> before using it.
            </summary>
            <param name="operationName">Operation's name <see cref="P:System.Diagnostics.Activity.OperationName"/></param>
        </member>
        <member name="M:System.Diagnostics.Activity.AddTag(System.String,System.String)">
            <summary>
            Update the Activity to have a tag with an additional 'key' and value 'value'.
            This shows up in the <see cref="P:System.Diagnostics.Activity.Tags"/>  enumeration.   It is meant for information that
            is useful to log but not needed for runtime control (for the latter, <see cref="P:System.Diagnostics.Activity.Baggage"/>)
            </summary>
            <returns>'this' for convenient chaining</returns>
        </member>
        <member name="M:System.Diagnostics.Activity.AddBaggage(System.String,System.String)">
            <summary>
            Update the Activity to have baggage with an additional 'key' and value 'value'.
            This shows up in the <see cref="P:System.Diagnostics.Activity.Baggage"/> enumeration as well as the <see cref="M:System.Diagnostics.Activity.GetBaggageItem(System.String)"/>
            method.
            Baggage is meant for information that is needed for runtime control.   For information 
            that is simply useful to show up in the log with the activity use <see cref="P:System.Diagnostics.Activity.Tags"/>.
            Returns 'this' for convenient chaining.
            </summary>
            <returns>'this' for convenient chaining</returns>
        </member>
        <member name="M:System.Diagnostics.Activity.SetParentId(System.String)">
            <summary>
            Updates the Activity To indicate that the activity with ID <paramref name="parentId"/>
            caused this activity.   This is intended to be used only at 'boundary' 
            scenarios where an activity from another process logically started 
            this activity. The Parent ID shows up the Tags (as well as the ParentID 
            property), and can be used to reconstruct the causal tree.  
            Returns 'this' for convenient chaining.
            </summary>
            <param name="parentId">The id of the parent operation.</param>
        </member>
        <member name="M:System.Diagnostics.Activity.SetStartTime(System.DateTime)">
            <summary>
            Update the Activity to set start time
            </summary>
            <param name="startTimeUtc">Activity start time in UTC (Greenwich Mean Time)</param>
            <returns>'this' for convenient chaining</returns>
        </member>
        <member name="M:System.Diagnostics.Activity.SetEndTime(System.DateTime)">
            <summary>
            Update the Activity to set <see cref="P:System.Diagnostics.Activity.Duration"/>
            as a difference between <see cref="P:System.Diagnostics.Activity.StartTimeUtc"/>
            and <paramref name="endTimeUtc"/>.
            </summary>
            <param name="endTimeUtc">Activity stop time in UTC (Greenwich Mean Time)</param>
            <returns>'this' for convenient chaining</returns>
        </member>
        <member name="P:System.Diagnostics.Activity.Duration">
            <summary>
            If the Activity has ended (<see cref="M:System.Diagnostics.Activity.Stop"/> or <see cref="M:System.Diagnostics.Activity.SetEndTime(System.DateTime)"/> was called) then this is the delta
            between <see cref="P:System.Diagnostics.Activity.StartTimeUtc"/> and end.   If Activity is not ended and <see cref="M:System.Diagnostics.Activity.SetEndTime(System.DateTime)"/> was not called then this is 
            <see cref="F:System.TimeSpan.Zero"/>.
            </summary>
        </member>
        <member name="M:System.Diagnostics.Activity.Start">
            <summary>
            Starts activity
            <list type="bullet">
            <item>Sets <see cref="P:System.Diagnostics.Activity.Parent"/> to hold <see cref="P:System.Diagnostics.Activity.Current"/>.</item>
            <item>Sets <see cref="P:System.Diagnostics.Activity.Current"/> to this activity.</item>
            <item>If <see cref="P:System.Diagnostics.Activity.StartTimeUtc"/> was not set previously, sets it to <see cref="P:System.DateTime.UtcNow"/>.</item>
            <item>Generates a unique <see cref="P:System.Diagnostics.Activity.Id"/> for this activity.</item>
            </list>
            Use <see cref="M:System.Diagnostics.DiagnosticSource.StartActivity(System.Diagnostics.Activity,System.Object)"/> to start activity and write start event.
            </summary>
            <seealso cref="M:System.Diagnostics.DiagnosticSource.StartActivity(System.Diagnostics.Activity,System.Object)"/>
            <seealso cref="M:System.Diagnostics.Activity.SetStartTime(System.DateTime)"/>
        </member>
        <member name="M:System.Diagnostics.Activity.Stop">
            <summary>
            Stops activity: sets <see cref="P:System.Diagnostics.Activity.Current"/> to <see cref="P:System.Diagnostics.Activity.Parent"/>.
            If end time was not set previously, sets <see cref="P:System.Diagnostics.Activity.Duration"/> as a difference between <see cref="P:System.DateTime.UtcNow"/> and <see cref="P:System.Diagnostics.Activity.StartTimeUtc"/>
            Use <see cref="M:System.Diagnostics.DiagnosticSource.StopActivity(System.Diagnostics.Activity,System.Object)"/>  to stop activity and write stop event.
            </summary>
            <seealso cref="M:System.Diagnostics.DiagnosticSource.StopActivity(System.Diagnostics.Activity,System.Object)"/>
            <seealso cref="M:System.Diagnostics.Activity.SetEndTime(System.DateTime)"/>
        </member>
        <member name="T:System.Diagnostics.Activity.KeyValueListNode">
            <summary>
            Having our own key-value linked list allows us to be more efficient  
            </summary>
        </member>
        <member name="P:System.Diagnostics.Activity.Current">
            <summary>
            Returns the current operation (Activity) for the current thread.  This flows 
            across async calls.
            </summary>
        </member>
        <member name="M:System.Diagnostics.Activity.GetUtcNow">
            <summary>
            Returns high resolution (~1 usec) current UTC DateTime.
            </summary>
        </member>
    </members>
</doc>