cache nuget packages
This commit is contained in:
master
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"version": 2,
|
||||
"contentHash": "tD6kosZnTAGdrEa0tZSuFyunMbt/5KYDnHdndJYGqZoNy00XVXyACd5d6KnE1YgYv3ne2CjtAfNXo/fwEhnKUA==",
|
||||
"source": "https://api.nuget.org/v3/index.json"
|
||||
}
|
||||
Binary file not shown.
@@ -0,0 +1,48 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
|
||||
<metadata minClientVersion="2.8.6">
|
||||
<id>System.Diagnostics.DiagnosticSource</id>
|
||||
<version>4.3.0</version>
|
||||
<title>System.Diagnostics.DiagnosticSource</title>
|
||||
<authors>Microsoft</authors>
|
||||
<owners>microsoft,dotnetframework</owners>
|
||||
<requireLicenseAcceptance>true</requireLicenseAcceptance>
|
||||
<licenseUrl>http://go.microsoft.com/fwlink/?LinkId=329770</licenseUrl>
|
||||
<projectUrl>https://dot.net/</projectUrl>
|
||||
<iconUrl>http://go.microsoft.com/fwlink/?LinkID=288859</iconUrl>
|
||||
<description>Provides Classes that allow you to decouple code logging rich (unserializable) diagnostics/telemetry (e.g. framework) from code that consumes it (e.g. tools)
|
||||
|
||||
Commonly Used Types:
|
||||
System.Diagnostics.DiagnosticListener
|
||||
System.Diagnostics.DiagnosticSource</description>
|
||||
<releaseNotes>https://go.microsoft.com/fwlink/?LinkID=799421</releaseNotes>
|
||||
<copyright>© Microsoft Corporation. All rights reserved.</copyright>
|
||||
<serviceable>true</serviceable>
|
||||
<dependencies>
|
||||
<group targetFramework="MonoAndroid1.0" />
|
||||
<group targetFramework="MonoTouch1.0" />
|
||||
<group targetFramework=".NETFramework4.5" />
|
||||
<group targetFramework=".NETFramework4.6" />
|
||||
<group targetFramework=".NETStandard1.1">
|
||||
<dependency id="System.Collections" version="4.3.0" />
|
||||
<dependency id="System.Diagnostics.Tracing" version="4.3.0" />
|
||||
<dependency id="System.Reflection" version="4.3.0" />
|
||||
<dependency id="System.Runtime" version="4.3.0" />
|
||||
<dependency id="System.Threading" version="4.3.0" />
|
||||
</group>
|
||||
<group targetFramework=".NETStandard1.3">
|
||||
<dependency id="System.Collections" version="4.3.0" />
|
||||
<dependency id="System.Diagnostics.Tracing" version="4.3.0" />
|
||||
<dependency id="System.Reflection" version="4.3.0" />
|
||||
<dependency id="System.Runtime" version="4.3.0" />
|
||||
<dependency id="System.Threading" version="4.3.0" />
|
||||
</group>
|
||||
<group targetFramework="Windows8.0" />
|
||||
<group targetFramework="WindowsPhoneApp8.1" />
|
||||
<group targetFramework="Xamarin.iOS1.0" />
|
||||
<group targetFramework="Xamarin.Mac2.0" />
|
||||
<group targetFramework="Xamarin.TVOS1.0" />
|
||||
<group targetFramework="Xamarin.WatchOS1.0" />
|
||||
</dependencies>
|
||||
</metadata>
|
||||
</package>
|
||||
@@ -0,0 +1,31 @@
|
||||
This Microsoft .NET Library may incorporate components from the projects listed
|
||||
below. Microsoft licenses these components under the Microsoft .NET Library
|
||||
software license terms. The original copyright notices and the licenses under
|
||||
which Microsoft received such components are set forth below for informational
|
||||
purposes only. Microsoft reserves all rights not expressly granted herein,
|
||||
whether by implication, estoppel or otherwise.
|
||||
|
||||
1. .NET Core (https://github.com/dotnet/core/)
|
||||
|
||||
.NET Core
|
||||
Copyright (c) .NET Foundation and Contributors
|
||||
|
||||
The MIT License (MIT)
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
@@ -0,0 +1,128 @@
|
||||
|
||||
MICROSOFT SOFTWARE LICENSE TERMS
|
||||
|
||||
|
||||
MICROSOFT .NET LIBRARY
|
||||
|
||||
These license terms are an agreement between Microsoft Corporation (or based on where you live, one of its affiliates) and you. Please read them. They apply to the software named above, which includes the media on which you received it, if any. The terms also apply to any Microsoft
|
||||
|
||||
· updates,
|
||||
|
||||
· supplements,
|
||||
|
||||
· Internet-based services, and
|
||||
|
||||
· support services
|
||||
|
||||
for this software, unless other terms accompany those items. If so, those terms apply.
|
||||
|
||||
BY USING THE SOFTWARE, YOU ACCEPT THESE TERMS. IF YOU DO NOT ACCEPT THEM, DO NOT USE THE SOFTWARE.
|
||||
|
||||
|
||||
IF YOU COMPLY WITH THESE LICENSE TERMS, YOU HAVE THE PERPETUAL RIGHTS BELOW.
|
||||
|
||||
1. INSTALLATION AND USE RIGHTS.
|
||||
|
||||
a. Installation and Use. You may install and use any number of copies of the software to design, develop and test your programs.
|
||||
|
||||
b. Third Party Programs. The software may include third party programs that Microsoft, not the third party, licenses to you under this agreement. Notices, if any, for the third party program are included for your information only.
|
||||
|
||||
2. ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.
|
||||
|
||||
a. DISTRIBUTABLE CODE. The software is comprised of Distributable Code. “Distributable Code” is code that you are permitted to distribute in programs you develop if you comply with the terms below.
|
||||
|
||||
i. Right to Use and Distribute.
|
||||
|
||||
· You may copy and distribute the object code form of the software.
|
||||
|
||||
· Third Party Distribution. You may permit distributors of your programs to copy and distribute the Distributable Code as part of those programs.
|
||||
|
||||
ii. Distribution Requirements. For any Distributable Code you distribute, you must
|
||||
|
||||
· add significant primary functionality to it in your programs;
|
||||
|
||||
· require distributors and external end users to agree to terms that protect it at least as much as this agreement;
|
||||
|
||||
· display your valid copyright notice on your programs; and
|
||||
|
||||
· indemnify, defend, and hold harmless Microsoft from any claims, including attorneys’ fees, related to the distribution or use of your programs.
|
||||
|
||||
iii. Distribution Restrictions. You may not
|
||||
|
||||
· alter any copyright, trademark or patent notice in the Distributable Code;
|
||||
|
||||
· use Microsoft’s trademarks in your programs’ names or in a way that suggests your programs come from or are endorsed by Microsoft;
|
||||
|
||||
· include Distributable Code in malicious, deceptive or unlawful programs; or
|
||||
|
||||
· modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification or distribution, that
|
||||
|
||||
· the code be disclosed or distributed in source code form; or
|
||||
|
||||
· others have the right to modify it.
|
||||
|
||||
3. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the software. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
|
||||
|
||||
· work around any technical limitations in the software;
|
||||
|
||||
· reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;
|
||||
|
||||
· publish the software for others to copy;
|
||||
|
||||
· rent, lease or lend the software;
|
||||
|
||||
· transfer the software or this agreement to any third party; or
|
||||
|
||||
· use the software for commercial software hosting services.
|
||||
|
||||
4. BACKUP COPY. You may make one backup copy of the software. You may use it only to reinstall the software.
|
||||
|
||||
5. DOCUMENTATION. Any person that has valid access to your computer or internal network may copy and use the documentation for your internal, reference purposes.
|
||||
|
||||
6. EXPORT RESTRICTIONS. The software is subject to United States export laws and regulations. You must comply with all domestic and international export laws and regulations that apply to the software. These laws include restrictions on destinations, end users and end use. For additional information, see www.microsoft.com/exporting.
|
||||
|
||||
7. SUPPORT SERVICES. Because this software is “as is,” we may not provide support services for it.
|
||||
|
||||
8. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates, Internet-based services and support services that you use, are the entire agreement for the software and support services.
|
||||
|
||||
9. APPLICABLE LAW.
|
||||
|
||||
a. United States. If you acquired the software in the United States, Washington state law governs the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws principles. The laws of the state where you live govern all other claims, including claims under state consumer protection laws, unfair competition laws, and in tort.
|
||||
|
||||
b. Outside the United States. If you acquired the software in any other country, the laws of that country apply.
|
||||
|
||||
10. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of your country. You may also have rights with respect to the party from whom you acquired the software. This agreement does not change your rights under the laws of your country if the laws of your country do not permit it to do so.
|
||||
|
||||
11. DISCLAIMER OF WARRANTY. THE SOFTWARE IS LICENSED “AS-IS.” YOU BEAR THE RISK OF USING IT. MICROSOFT GIVES NO EXPRESS WARRANTIES, GUARANTEES OR CONDITIONS. YOU MAY HAVE ADDITIONAL CONSUMER RIGHTS OR STATUTORY GUARANTEES UNDER YOUR LOCAL LAWS WHICH THIS AGREEMENT CANNOT CHANGE. TO THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS, MICROSOFT EXCLUDES THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
|
||||
|
||||
FOR AUSTRALIA – YOU HAVE STATUTORY GUARANTEES UNDER THE AUSTRALIAN CONSUMER LAW AND NOTHING IN THESE TERMS IS INTENDED TO AFFECT THOSE RIGHTS.
|
||||
|
||||
12. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM MICROSOFT AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO U.S. $5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES.
|
||||
|
||||
This limitation applies to
|
||||
|
||||
· anything related to the software, services, content (including code) on third party Internet sites, or third party programs; and
|
||||
|
||||
· claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or other tort to the extent permitted by applicable law.
|
||||
|
||||
It also applies even if Microsoft knew or should have known about the possibility of the damages. The above limitation or exclusion may not apply to you because your country may not allow the exclusion or limitation of incidental, consequential or other damages.
|
||||
|
||||
Please note: As this software is distributed in Quebec, Canada, some of the clauses in this agreement are provided below in French.
|
||||
|
||||
Remarque : Ce logiciel étant distribué au Québec, Canada, certaines des clauses dans ce contrat sont fournies ci-dessous en français.
|
||||
|
||||
EXONÉRATION DE GARANTIE. Le logiciel visé par une licence est offert « tel quel ». Toute utilisation de ce logiciel est à votre seule risque et péril. Microsoft n’accorde aucune autre garantie expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection des consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contrefaçon sont exclues.
|
||||
|
||||
LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAGES. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation pour les autres dommages, y compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices.
|
||||
|
||||
Cette limitation concerne :
|
||||
|
||||
· tout ce qui est relié au logiciel, aux services ou au contenu (y compris le code) figurant sur des sites Internet tiers ou dans des programmes tiers ; et
|
||||
|
||||
· les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité stricte, de négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur.
|
||||
|
||||
Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel dommage. Si votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages indirects, accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus ne s’appliquera pas à votre égard.
|
||||
|
||||
EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits prévus par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois de votre pays si celles-ci ne le permettent pas.
|
||||
|
||||
|
||||
@@ -0,0 +1,464 @@
|
||||
<?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="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 overload 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}})">
|
||||
<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(System.String)">
|
||||
<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, all serializable parts of
|
||||
every DiagnosticSource event will be forwarded (this is NOT recommended for monitoring but
|
||||
can be useful for discovery).
|
||||
|
||||
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 Diagnostic sources is logged to the 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>
|
||||
</members>
|
||||
</doc>
|
||||
@@ -0,0 +1,428 @@
|
||||
<?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="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 overload 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}})">
|
||||
<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(System.String)">
|
||||
<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, all serializable parts of
|
||||
every DiagnosticSource event will be forwarded (this is NOT recommended for monitoring but
|
||||
can be useful for discovery).
|
||||
|
||||
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 Diagnostic sources is logged to the 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.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.NewDiagnosticListener(System.String)">
|
||||
<summary>
|
||||
Fires when a new DiagnosticSource becomes available.
|
||||
</summary>
|
||||
<param name="SourceName"></param>
|
||||
</member>
|
||||
<member name="M:System.Diagnostics.DiagnosticSourceEventSource.ToJson(System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
|
||||
<summary>
|
||||
Converts a keyvalue bag to JSON. Only used on V4.5 EventSources.
|
||||
</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>
|
||||
</members>
|
||||
</doc>
|
||||
@@ -0,0 +1,464 @@
|
||||
<?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="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 overload 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}})">
|
||||
<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(System.String)">
|
||||
<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, all serializable parts of
|
||||
every DiagnosticSource event will be forwarded (this is NOT recommended for monitoring but
|
||||
can be useful for discovery).
|
||||
|
||||
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 Diagnostic sources is logged to the 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>
|
||||
</members>
|
||||
</doc>
|
||||
@@ -0,0 +1,428 @@
|
||||
<?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="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 overload 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}})">
|
||||
<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(System.String)">
|
||||
<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, all serializable parts of
|
||||
every DiagnosticSource event will be forwarded (this is NOT recommended for monitoring but
|
||||
can be useful for discovery).
|
||||
|
||||
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 Diagnostic sources is logged to the 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.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.NewDiagnosticListener(System.String)">
|
||||
<summary>
|
||||
Fires when a new DiagnosticSource becomes available.
|
||||
</summary>
|
||||
<param name="SourceName"></param>
|
||||
</member>
|
||||
<member name="M:System.Diagnostics.DiagnosticSourceEventSource.ToJson(System.Collections.Generic.IEnumerable{System.Collections.Generic.KeyValuePair{System.String,System.String}})">
|
||||
<summary>
|
||||
Converts a keyvalue bag to JSON. Only used on V4.5 EventSources.
|
||||
</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>
|
||||
</members>
|
||||
</doc>
|
||||
Binary file not shown.
@@ -0,0 +1 @@
|
||||
j1TfX/OCtmUOLhDRBDhjokv0n/BxTneeg3zXBz5G+yY1vPzc+Z18Sp2V816//YarDKBoMF9LJFBy4IMDuRezTQ==
|
||||
Reference in New Issue
Block a user