Remove .NET Framework remarks (System.Diagnostics) (#12644)

Author: gewarren

xml/System.Diagnostics.Contracts/Contract.xml

@@ -409,7 +409,7 @@
 ## Remarks
  The event information for this event is supplied by the <xref:System.Diagnostics.Contracts.ContractFailedEventArgs?displayProperty=nameWithType> object that is passed to the event handler. This event notifies a managed application environment such as an interactive interpreter or a Web browser host that a contract has failed. Before doing so, it will raise an event that an application can handle as it sees fit. For example, if code is being run in a testing framework, you can log a test failure and then end the test.
 
- The default implementation of the <xref:System.Diagnostics.Contracts.Internal.ContractHelper.RaiseContractFailedEvent*> method in the .NET Framework class library is to call each handler that is registered with the <xref:System.Diagnostics.Contracts.Contract.ContractFailed> event. Exceptions thrown by handlers are ignored, but each handler can indicate whether the failure is handled by calling the <xref:System.Diagnostics.Contracts.ContractFailedEventArgs.SetHandled*> method for the event arguments. If any handler sets the failure as handled, the method returns `null` and no further action is taken. Alternatively, handlers can call the <xref:System.Diagnostics.Contracts.ContractFailedEventArgs.SetUnwind*> method to instruct the code to unwind. In that case, an exception is thrown after all handlers have executed.
+ The default implementation of the <xref:System.Diagnostics.Contracts.Internal.ContractHelper.RaiseContractFailedEvent*> method is to call each handler that is registered with the <xref:System.Diagnostics.Contracts.Contract.ContractFailed> event. Exceptions thrown by handlers are ignored, but each handler can indicate whether the failure is handled by calling the <xref:System.Diagnostics.Contracts.ContractFailedEventArgs.SetHandled*> method for the event arguments. If any handler sets the failure as handled, the method returns `null` and no further action is taken. Alternatively, handlers can call the <xref:System.Diagnostics.Contracts.ContractFailedEventArgs.SetUnwind*> method to instruct the code to unwind. In that case, an exception is thrown after all handlers have executed.
 
  ]]></format>
         </remarks>

xml/System.Diagnostics.Contracts/ContractFailedEventArgs.xml

@@ -53,7 +53,7 @@
       <format type="text/markdown"><![CDATA[
 
 ## Remarks
- A <xref:System.Diagnostics.Contracts.ContractFailedEventArgs> object is passed to the <xref:System.Diagnostics.Contracts.Contract.ContractFailed?displayProperty=nameWithType> event when a contract fails. The <xref:System.Diagnostics.Contracts.Contract.ContractFailed> event enables a managed application environment such as an interactive interpreter, a Web browser host, a test harness, or a logging infrastructure to be notified of contract failures. The event requires full trust.
+ A <xref:System.Diagnostics.Contracts.ContractFailedEventArgs> object is passed to the <xref:System.Diagnostics.Contracts.Contract.ContractFailed?displayProperty=nameWithType> event when a contract fails. The <xref:System.Diagnostics.Contracts.Contract.ContractFailed> event enables a managed application environment such as an interactive interpreter, a Web browser host, a test harness, or a logging infrastructure to be notified of contract failures.
 
  ]]></format>
     </remarks>

xml/System.Diagnostics.PerformanceData/CounterData.xml

@@ -255,14 +255,9 @@
 ## Remarks
  This property provides safe access to the counter data for multi-threaded applications. If performance is of primary concern, use the <xref:System.Diagnostics.PerformanceData.CounterData.RawValue> property; however, the <xref:System.Diagnostics.PerformanceData.CounterData.RawValue> property is not thread safe.
 
- Note that the <xref:System.Diagnostics.PerformanceData.CounterData.Value> property is not thread safe in .NET Framework 3.5.
-
  To increment the counter value, consider using the <xref:System.Diagnostics.PerformanceData.CounterData.Increment*> or <xref:System.Diagnostics.PerformanceData.CounterData.IncrementBy*> method.
 
-
-
-## Examples
- For an example, see <xref:System.Diagnostics.PerformanceData>.
+For an example, see <xref:System.Diagnostics.PerformanceData>.
 
  ]]></format>
         </remarks>

xml/System.Diagnostics.Tracing/EventListener.xml

@@ -61,16 +61,16 @@
       <format type="text/markdown"><![CDATA[
 
 ## Remarks
- An event listener represents the target for all events generated by event source (<xref:System.Diagnostics.Tracing.EventSource> object) implementations in the current application domain. When a new event listener is created, it is logically attached to all event sources in that application domain.
+ An event listener represents the target for all events generated by event source (<xref:System.Diagnostics.Tracing.EventSource> object) implementations. When a new event listener is created, it is logically attached to all event sources.
 
 > [!NOTE]
->  This type implements the <xref:System.IDisposable> interface. When you have finished using the type, you must dispose of it either directly or indirectly. To dispose of the type directly, call its <xref:System.IDisposable.Dispose*> method in a `try`/`catch` block. To dispose of it indirectly, use a language construct such as `using` (in C#) or `Using` (in Visual Basic). For more information, see the "Using an Object that Implements IDisposable" section in the <xref:System.IDisposable> interface topic.
+> This type implements the <xref:System.IDisposable> interface. When you have finished using the type, you must dispose of it either directly or indirectly. To dispose of the type directly, call its <xref:System.IDisposable.Dispose*> method in a `try`/`catch` block. To dispose of it indirectly, use a language construct such as `using` in C#.
 
  An event listener can enable or disable on a per-current event source basis by using event levels (<xref:System.Diagnostics.Tracing.EventLevel>) and event keywords (<xref:System.Diagnostics.Tracing.EventKeywords>) to further restrict the set of events to be sent to the listener. The listener can also send arbitrary commands to a specific current event source by using the <xref:System.Diagnostics.Tracing.EventSource.SendCommand*> method. The meanings of the commands are specific to the implementation of the event source.
 
- Multiple event listeners can be defined in a single application domain. Each listener is logically independent of the other listeners so that events that are enabled or disabled by one listener affect only that listener. It is possible for commands sent with the <xref:System.Diagnostics.Tracing.EventSource.SendCommand*> method to do a semantic operation (such as a garbage collection or flushing data) that affects the other listeners, but this is the exception rather than the rule.
+ Multiple event listeners can be defined. Each listener is logically independent of the other listeners so that events that are enabled or disabled by one listener affect only that listener. It is possible for commands sent with the <xref:System.Diagnostics.Tracing.EventSource.SendCommand*> method to do a semantic operation (such as a garbage collection or flushing data) that affects the other listeners, but this is the exception rather than the rule.
 
- Each event source   keeps a list of event listeners that it sends events to. A set of filtering criteria is associated with each event source-listener pair. These criteria determine the events that listener will receive for the current event source. Listeners receive the events on their <xref:System.Diagnostics.Tracing.EventListener.OnEventWritten*> method. Therefore, subclasses of <xref:System.Diagnostics.Tracing.EventListener> must override this method to do something useful with the data.
+ Each event source keeps a list of event listeners that it sends events to. A set of filtering criteria is associated with each event source-listener pair. These criteria determine the events that listener will receive for the current event source. Listeners receive the events on their <xref:System.Diagnostics.Tracing.EventListener.OnEventWritten*> method. Therefore, subclasses of <xref:System.Diagnostics.Tracing.EventListener> must override this method to do something useful with the data.
 
  When a new event source is created, the <xref:System.Diagnostics.Tracing.EventListener.OnEventSourceCreated*> method is called. Every current event listener gets exactly one <xref:System.Diagnostics.Tracing.EventListener.OnEventSourceCreated*> call for every current event source that can send it log messages. When an event listener is created, a series of <xref:System.Diagnostics.Tracing.EventListener.OnEventSourceCreated*> calls are made to notify the new listener of all the event sources that existed before the listener was created.
 
@@ -489,7 +489,7 @@
           <format type="text/markdown"><![CDATA[
 
 ## Remarks
- The value returned by <xref:System.Diagnostics.Tracing.EventListener.EventSourceIndex*> identifies an event source that is suitable for indexing an array. This integer is unique within the application domain. An event listener might find it useful to store additional information about each event source that is connected to it. The value returned by <xref:System.Diagnostics.Tracing.EventListener.EventSourceIndex*> allows this extra information to be efficiently stored in an expandable array such as `List<T>`.
+ The value returned by <xref:System.Diagnostics.Tracing.EventListener.EventSourceIndex*> identifies an event source that is suitable for indexing an array. An event listener might find it useful to store additional information about each event source that is connected to it. The value returned by <xref:System.Diagnostics.Tracing.EventListener.EventSourceIndex*> allows this extra information to be efficiently stored in an expandable array such as `List<T>`.
 
  ]]></format>
         </remarks>

xml/System.Diagnostics.Tracing/EventWrittenEventArgs.xml

@@ -469,7 +469,7 @@
         <ReturnType>System.Int64</ReturnType>
       </ReturnValue>
       <Docs>
-        <summary>Gets the thread identifier for the OS thread that wrote the event. (.NET Core 2.2 and later only.)</summary>
+        <summary>Gets the thread identifier for the OS thread that wrote the event.</summary>
         <value>The thread identifier for the OS thread that wrote the event.</value>
         <remarks>To be added.</remarks>
       </Docs>
@@ -723,7 +723,7 @@
         <ReturnType>System.DateTime</ReturnType>
       </ReturnValue>
       <Docs>
-        <summary>Gets the time that the event was originally generated as a <see cref="T:System.DateTime" /> timestamp. (.NET Core 2.2 and later only.)</summary>
+        <summary>Gets the time that the event was originally generated as a <see cref="T:System.DateTime" /> timestamp.</summary>
         <value>The date and time when the event was logged. The system tries to be as precise as possible. </value>
         <remarks>To be added.</remarks>
       </Docs>

xml/System.Diagnostics/BooleanSwitch.xml

@@ -64,40 +64,17 @@
 
 You can create a <xref:System.Diagnostics.BooleanSwitch> in your code and set the <xref:System.Diagnostics.BooleanSwitch.Enabled> property directly to instrument a specific section of code.
 
-For .NET Framework apps only, you can also enable or disable a <xref:System.Diagnostics.BooleanSwitch> through the application configuration file and then use the configured <xref:System.Diagnostics.BooleanSwitch> value in your application. To configure a <xref:System.Diagnostics.BooleanSwitch>, edit the configuration file that corresponds to the name of your application. Within this file, you can add or remove a switch, set a switch's value, or clear all the switches previously set by the application. The configuration file should be formatted like the following example.
+The <xref:System.Diagnostics.BooleanSwitch.Enabled> property of the new switch is set to `false` by default.
 
-```xml
-<configuration>
-  <system.diagnostics>
-    <switches>
-      <add name="mySwitch" value="1"/>
-    </switches>
-  </system.diagnostics>
-</configuration>
-```
-
- This example configuration section defines a <xref:System.Diagnostics.BooleanSwitch> with the <xref:System.Diagnostics.Switch.DisplayName> property set to `mySwitch` and the <xref:System.Diagnostics.BooleanSwitch.Enabled*> value set to `true`. Within your .NET Framework application, you can use the configured switch value by creating a <xref:System.Diagnostics.BooleanSwitch> with the same name, as shown in the following code example.
-
- :::code language="csharp" source="~/snippets/csharp/System.Diagnostics/BooleanSwitch/Overview/remarks.cs" id="Snippet2":::
- :::code language="vb" source="~/snippets/visualbasic/System.Diagnostics/BooleanSwitch/Overview/remarks.vb" id="Snippet2":::
-
-For .NET Core and .NET 5+ apps, the <xref:System.Diagnostics.BooleanSwitch.Enabled> property of the new switch is set to `false` by default.
-
-For .NET Framework apps, the <xref:System.Diagnostics.BooleanSwitch.Enabled> property is set using the value specified in the configuration file. Configure the switch with a value of 0 to set the <xref:System.Diagnostics.BooleanSwitch.Enabled> property to `false`; configure the switch with a nonzero value to set the <xref:System.Diagnostics.BooleanSwitch.Enabled> property to `true`. If the <xref:System.Diagnostics.BooleanSwitch> constructor cannot find initial switch settings in the configuration file, the <xref:System.Diagnostics.BooleanSwitch.Enabled> property of the new switch is set to `false`.
-
- You must enable tracing or debugging to use a switch. The following syntax is compiler specific. If you use compilers other than C# or Visual Basic, refer to the documentation for your compiler.
-
-- To enable debugging in C#, add the `/d:DEBUG` flag to the compiler command line when you compile your code, or you can add `#define DEBUG` to the top of your file. In Visual Basic, add the `/d:DEBUG=True` flag to the compiler command line.
-
-- To enable tracing in C#, add the `/d:TRACE` flag to the compiler command line when you compile your code, or add `#define TRACE` to the top of your file. In Visual Basic, add the `/d:TRACE=True` flag to the compiler command line.
+ You must enable tracing or debugging to use a switch.
 
 > [!NOTE]
->  These debug and trace compiler switches are not required when using the <xref:System.Diagnostics.BooleanSwitch> class in isolation. They are only required in conjunction with <xref:System.Diagnostics.Trace> or <xref:System.Diagnostics.Debug> methods that are conditionally compiled.
+> These debug and trace compiler switches are not required when using the <xref:System.Diagnostics.BooleanSwitch> class in isolation. They are only required in conjunction with <xref:System.Diagnostics.Trace> or <xref:System.Diagnostics.Debug> methods that are conditionally compiled.
 
- For more information on instrumenting your application, see <xref:System.Diagnostics.Debug> and <xref:System.Diagnostics.Trace>. For more information about configuring and using trace switches, see [Trace Switches](/dotnet/framework/debug-trace-profile/trace-switches).
+ For more information on instrumenting your application, see <xref:System.Diagnostics.Debug> and <xref:System.Diagnostics.Trace>
 
 > [!NOTE]
->  To improve performance, you can make <xref:System.Diagnostics.BooleanSwitch> members `static` in your class.
+> To improve performance, you can make <xref:System.Diagnostics.BooleanSwitch> members `static` in your class.
 
 ## Examples
  The following example creates a <xref:System.Diagnostics.BooleanSwitch> and uses the switch to determine whether to print an error message. You create the switch at the class level. The `Main` method passes its location to `MyMethod`, which prints an error message and where the error occurred.
@@ -177,25 +154,7 @@ For .NET Framework apps, the <xref:System.Diagnostics.BooleanSwitch.Enabled> pro
           <format type="text/markdown"><![CDATA[
 
 ## Remarks
- When you create a <xref:System.Diagnostics.BooleanSwitch>, the `displayName` parameter is used to find the initial switch settings for .NET Framework apps in the application configuration file. If the constructor cannot find initial settings, or for .NET Core and .NET 5+ apps, the <xref:System.Diagnostics.BooleanSwitch.Enabled> property is set to `false` (disabled).
-
- To set the level of your <xref:System.Diagnostics.BooleanSwitch> in a .NET Framework app, edit the configuration file corresponding to the name of your application. Within this file, you can add a switch and set its value, remove a switch, or clear all switches previously set by the application. The configuration file should be formatted like the following example:
-
-```xml
-<configuration>
-    <system.diagnostics>
-       <switches>
-          <add name="mySwitch" value="10" />
-          <add name="myNewSwitch" value="20" />
-          <remove name="mySwitch" />
-          <clear/>
-       </switches>
-    </system.diagnostics>
- </configuration>
-```
-
-> [!NOTE]
-> The switches you created should be `static`.
+ When you create a <xref:System.Diagnostics.BooleanSwitch>, the <xref:System.Diagnostics.BooleanSwitch.Enabled> property is set to `false` (disabled).
 
 ## Examples
  The following example creates a <xref:System.Diagnostics.BooleanSwitch> and uses the switch to determine whether to print an error message. The switch is created at the class level. The `Main` method passes its location to `MyMethod`, which prints an error message and where the error occurred.