Make xrefs more readable

docs/fundamentals/runtime-libraries/includes/stringbuilder-perf-note.md

@@ -1,16 +1,16 @@
-Using character-based indexing with the <xref:System.Text.StringBuilder.Chars%2A> property can be extremely slow under the following conditions:
+Using character-based indexing with the <xref:System.Text.StringBuilder.Chars(System.Int32)> property can be extremely slow under the following conditions:
 
 - The <xref:System.Text.StringBuilder> instance is large (for example, it consists of several tens of thousands of characters).
-- The <xref:System.Text.StringBuilder> is "chunky." That is, repeated calls to methods such as <xref:System.Text.StringBuilder.Append%2A?displayProperty=nameWithType> have automatically expanded the object's <xref:System.Text.StringBuilder.Capacity%2A?displayProperty=nameWithType> property and allocated new chunks of memory to it.
+- The <xref:System.Text.StringBuilder> is "chunky." That is, repeated calls to methods such as <xref:System.Text.StringBuilder.Append*?displayProperty=nameWithType> have automatically expanded the object's <xref:System.Text.StringBuilder.Capacity*?displayProperty=nameWithType> property and allocated new chunks of memory to it.
 
 Performance is severely impacted because each character access walks the entire linked list of chunks to find the correct buffer to index into.
 
 > [!NOTE]
-> Even for a large "chunky" <xref:System.Text.StringBuilder> object, using the <xref:System.Text.StringBuilder.Chars%2A> property for index-based access to one or a small number of characters has a negligible performance impact; typically, it is an **O(n)** operation. The significant performance impact occurs when iterating the characters in the <xref:System.Text.StringBuilder> object, which is an **O(n^2)** operation.
+> Even for a large "chunky" <xref:System.Text.StringBuilder> object, using the <xref:System.Text.StringBuilder.Chars(System.Int32)> property for index-based access to one or a small number of characters has a negligible performance impact; typically, it is an **O(n)** operation. The significant performance impact occurs when iterating the characters in the <xref:System.Text.StringBuilder> object, which is an **O(n^2)** operation.
 
 If you encounter performance issues when using character-based indexing with <xref:System.Text.StringBuilder> objects, you can use any of the following workarounds:
 
-- Convert the <xref:System.Text.StringBuilder> instance to a <xref:System.String> by calling the <xref:System.Text.StringBuilder.ToString%2A> method, then access the characters in the string.
+- Convert the <xref:System.Text.StringBuilder> instance to a <xref:System.String> by calling the <xref:System.Text.StringBuilder.ToString*> method, then access the characters in the string.
 
 - Copy the contents of the existing <xref:System.Text.StringBuilder> object to a new pre-sized <xref:System.Text.StringBuilder> object. Performance improves because the new <xref:System.Text.StringBuilder> object is not chunky. For example:
 

docs/fundamentals/runtime-libraries/microsoft-win32-registry.md

@@ -27,7 +27,7 @@ Hardware devices can place information in the registry automatically using the P
 
 ## Static methods for getting and setting values
 
-The <xref:Microsoft.Win32.Registry> class also contains `static` <xref:Microsoft.Win32.Registry.GetValue%2A> and <xref:Microsoft.Win32.Registry.SetValue%2A> methods for setting and retrieving values from registry keys. These methods open and close registry keys each time they're used. So when you access a large number of values, they don't perform as well as analogous methods in the <xref:Microsoft.Win32.RegistryKey> class.
+The <xref:Microsoft.Win32.Registry> class also contains `static` <xref:Microsoft.Win32.Registry.GetValue*> and <xref:Microsoft.Win32.Registry.SetValue*> methods for setting and retrieving values from registry keys. These methods open and close registry keys each time they're used. So when you access a large number of values, they don't perform as well as analogous methods in the <xref:Microsoft.Win32.RegistryKey> class.
 
 The <xref:Microsoft.Win32.RegistryKey> class also provides methods that allow you to:
 

docs/fundamentals/runtime-libraries/system-appcontext.md

@@ -26,13 +26,13 @@ It's beneficial to use a consistent format for switch names, since they're a for
 - *Switch*.*namespace*.*switchname*
 - *Switch*.*library*.*switchname*
 
-Once you define and document the switch, callers can use it by calling the <xref:System.AppContext.SetSwitch%28System.String%2CSystem.Boolean%29?displayProperty=nameWithType> method programmatically. .NET Framework apps can also use the switch by adding an [`<AppContextSwitchOverrides>`](../../framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md) element to their application configuration file or by using the registry. For more information about how callers use and set the value of <xref:System.AppContext> configuration switches, see the [AppContext for library consumers](#appcontext-for-library-consumers) section.
+Once you define and document the switch, callers can use it by calling the <xref:System.AppContext.SetSwitch(System.String,System.Boolean)?displayProperty=nameWithType> method programmatically. .NET Framework apps can also use the switch by adding an [`<AppContextSwitchOverrides>`](../../framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md) element to their application configuration file or by using the registry. For more information about how callers use and set the value of <xref:System.AppContext> configuration switches, see the [AppContext for library consumers](#appcontext-for-library-consumers) section.
 
-In .NET Framework, when the common language runtime runs an application, it automatically reads the registry's compatibility settings and loads the application configuration file to populate the application's <xref:System.AppContext> instance. Because the <xref:System.AppContext> instance is populated either programmatically by the caller or by the runtime, .NET Framework apps don't have to take any action, such as calling the <xref:System.AppContext.SetSwitch%2A> method, to configure the <xref:System.AppContext> instance.
+In .NET Framework, when the common language runtime runs an application, it automatically reads the registry's compatibility settings and loads the application configuration file to populate the application's <xref:System.AppContext> instance. Because the <xref:System.AppContext> instance is populated either programmatically by the caller or by the runtime, .NET Framework apps don't have to take any action, such as calling the <xref:System.AppContext.SetSwitch*> method, to configure the <xref:System.AppContext> instance.
 
 ### Check the setting
 
-You can check if a consumer has declared the value of the switch and act appropriately by calling the <xref:System.AppContext.TryGetSwitch%2A?displayProperty=nameWithType> method. The method returns `true` if the `switchName` argument is found, and its `isEnabled` argument indicates the value of the switch. Otherwise, the method returns `false`.
+You can check if a consumer has declared the value of the switch and act appropriately by calling the <xref:System.AppContext.TryGetSwitch*?displayProperty=nameWithType> method. The method returns `true` if the `switchName` argument is found, and its `isEnabled` argument indicates the value of the switch. Otherwise, the method returns `false`.
 
 ### Example
 
@@ -86,7 +86,7 @@ When the application is run with the configuration file present, it produces the
 
 If you're the consumer of a library, the <xref:System.AppContext> class allows you to take advantage of a library or library method's opt-out mechanism for new functionality. Individual methods of the class library that you are calling define particular switches that enable or disable a new behavior. The value of the switch is a Boolean. If it is `false`, which is typically the default value, the new behavior is enabled; if it is `true`, the new behavior is disabled, and the member behaves as it did previously.
 
-You can set the value of a switch by calling the <xref:System.AppContext.SetSwitch%28System.String%2CSystem.Boolean%29?displayProperty=nameWithType> method in your code. The `switchName` argument defines the switch name, and the `isEnabled` property defines the value of the switch. Because <xref:System.AppContext> is a static class, it is available on a per-application domain basis. Calling the <xref:System.AppContext.SetSwitch%28System.String%2CSystem.Boolean%29?displayProperty=nameWithType> has application scope; that is, it affects only the application.
+You can set the value of a switch by calling the <xref:System.AppContext.SetSwitch(System.String,System.Boolean)?displayProperty=nameWithType> method in your code. The `switchName` argument defines the switch name, and the `isEnabled` property defines the value of the switch. Because <xref:System.AppContext> is a static class, it is available on a per-application domain basis. Calling the <xref:System.AppContext.SetSwitch(System.String,System.Boolean)?displayProperty=nameWithType> has application scope; that is, it affects only the application.
 
 .NET Framework apps have additional ways to set the value of a switch:
 

docs/fundamentals/runtime-libraries/system-appdomain-unhandledexception.md

@@ -30,6 +30,6 @@ For more information about handling events, see [Handling and Raising Events](..
 
 For certain application models, the <xref:System.AppDomain.UnhandledException> event can be preempted by other events if the unhandled exception occurs in the main application thread.
 
-In applications that use Windows Forms, unhandled exceptions in the main application thread cause the <xref:System.Windows.Forms.Application.ThreadException?displayProperty=nameWithType> event to be raised. If this event is handled, the default behavior is that the unhandled exception does not terminate the application, although the application is left in an unknown state. In that case, the <xref:System.AppDomain.UnhandledException> event is not raised. This behavior can be changed by using the application configuration file, or by using the <xref:System.Windows.Forms.Application.SetUnhandledExceptionMode%2A?displayProperty=nameWithType> method to change the mode to <xref:System.Windows.Forms.UnhandledExceptionMode.ThrowException?displayProperty=nameWithType> before the <xref:System.Windows.Forms.Application.ThreadException> event handler is hooked up. This applies only to the main application thread. The <xref:System.AppDomain.UnhandledException> event is raised for unhandled exceptions thrown in other threads.
+In applications that use Windows Forms, unhandled exceptions in the main application thread cause the <xref:System.Windows.Forms.Application.ThreadException?displayProperty=nameWithType> event to be raised. If this event is handled, the default behavior is that the unhandled exception does not terminate the application, although the application is left in an unknown state. In that case, the <xref:System.AppDomain.UnhandledException> event is not raised. This behavior can be changed by using the application configuration file, or by using the <xref:System.Windows.Forms.Application.SetUnhandledExceptionMode*?displayProperty=nameWithType> method to change the mode to <xref:System.Windows.Forms.UnhandledExceptionMode.ThrowException?displayProperty=nameWithType> before the <xref:System.Windows.Forms.Application.ThreadException> event handler is hooked up. This applies only to the main application thread. The <xref:System.AppDomain.UnhandledException> event is raised for unhandled exceptions thrown in other threads.
 
 The Visual Basic application framework provides another event for unhandled exceptions in the main application thread&mdash;the <xref:Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.UnhandledException?displayProperty=nameWithType> event. This event has an event arguments object with the same name as the event arguments object used by <xref:System.AppDomain.UnhandledException?displayProperty=nameWithType>, but with different properties. In particular, this event arguments object has an <xref:Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs.ExitApplication> property that allows the application to continue running, ignoring the unhandled exception (and leaving the application in an unknown state). In that case, the <xref:System.AppDomain.UnhandledException?displayProperty=nameWithType> event is not raised.