remove lost links

Author: gewarren

xml/System.Management.Instrumentation/WmiProviderInstallationException.xml

@@ -23,7 +23,7 @@
   <Docs>
     <summary>Represents an exception to throw when WMI provider installation fails.
 
- Note: the WMI .NET libraries are now considered in final state, and no further development, enhancements, or updates will be available for non-security related issues affecting these libraries. The <see href="https://learn.microsoft.com/en-us/).aspx">MI APIs</see> should be used for all new development.</summary>
+ Note: the WMI .NET libraries are now considered in final state, and no further development, enhancements, or updates will be available for non-security related issues affecting these libraries. Use the MI APIs for all new development.</summary>
     <remarks>To be added.</remarks>
   </Docs>
   <Members>

xml/System.Net/WebRequest.xml

@@ -1332,7 +1332,7 @@
 
 ## Remarks
 
-This property allows an application to determine which <xref:System.Net.IWebRequestCreate> derived factory object was used to create the request. This object may be [System.Net.Browser.WebRequestCreator.BrowserHttp](https://learn.microsoft.com/en-us/)) or [System.Net.Browser.WebRequestCreator.ClientHttp](https://learn.microsoft.com/en-us/)), but it may also be a custom instance derived from <xref:System.Net.IWebRequestCreate>. This allows an application to determine whether the browser hosting Silverlight, the Silverlight client, or some custom object handles HTTP requests and responses for the <xref:System.Net.WebRequest> instance. The <xref:System.Net.WebRequest.RegisterPrefix*> method allows an application to configure which derived <xref:System.Net.WebRequest> type will be instantiated when making a request to a specific URI. <xref:System.Net.WebRequest> creators are typically registered to handle a specific protocol, such HTTP or HTTPS, but can be registered to handle a request to a specific server or path on a server. This is useful when more than one derived <xref:System.Net.WebRequest> type can process requests for the same protocol. The Microsoft Silverlight 3 and later runtime supports multiple HTTP handlers each having different capabilities. For example, a web service that uses Representational State Transfer (REST) might require the [System.Net.Browser.WebRequestCreator.ClientHttp](https://learn.microsoft.com/en-us/)) handler while a SOAP web service might be able to use the default [System.Net.Browser.WebRequestCreator.BrowserHttp](https://learn.microsoft.com/en-us/)) handler.
+This property allows an application to determine which <xref:System.Net.IWebRequestCreate> derived factory object was used to create the request. This object may be System.Net.Browser.WebRequestCreator.BrowserHttp or System.Net.Browser.WebRequestCreator.ClientHttp, but it may also be a custom instance derived from <xref:System.Net.IWebRequestCreate>. This allows an application to determine whether the browser hosting Silverlight, the Silverlight client, or some custom object handles HTTP requests and responses for the <xref:System.Net.WebRequest> instance. The <xref:System.Net.WebRequest.RegisterPrefix*> method allows an application to configure which derived <xref:System.Net.WebRequest> type will be instantiated when making a request to a specific URI. <xref:System.Net.WebRequest> creators are typically registered to handle a specific protocol, such HTTP or HTTPS, but can be registered to handle a request to a specific server or path on a server. This is useful when more than one derived <xref:System.Net.WebRequest> type can process requests for the same protocol. The Microsoft Silverlight 3 and later runtime supports multiple HTTP handlers each having different capabilities. For example, a web service that uses Representational State Transfer (REST) might require the System.Net.Browser.WebRequestCreator.ClientHttp handler while a SOAP web service might be able to use the default System.Net.Browser.WebRequestCreator.BrowserHttp handler.
 
  ]]></format>
         </remarks>

xml/System.Runtime.InteropServices/CoClassAttribute.xml

@@ -66,15 +66,15 @@
   <Docs>
     <summary>Specifies the class identifier of a coclass imported from a type library.</summary>
     <remarks>
-      <format type="text/markdown"><![CDATA[  
-  
-## Remarks  
- You can apply this attribute to coclass interfaces, although the [Tlbimp.exe (Type Library Importer)](/dotnet/framework/tools/tlbimp-exe-type-library-importer) typically applies it for you when it imports a type library.  
-  
- When Tlbimp.exe imports a coclass, it produces a managed class and an interface to represent the coclass. The coclass interface has the same interface identifier (IID) as the default interface of the original coclass. The imported coclass interface also retains the name of the coclass. Tlbimp.exe appends the original coclass name with "class" to identify the imported class.  
-  
- You rarely apply this attribute. However, if you plan to write source code that produces metadata that closely simulates metadata produced by Tlbimp.exe, you should create a coclass interface for each coclass. Use the name of the original coclass to name the coclass interface and derive it from the default interface. In addition to the <xref:System.Runtime.InteropServices.CoClassAttribute>, you must also apply the <xref:System.Runtime.InteropServices.ComImportAttribute?displayProperty=nameWithType> and <xref:System.Runtime.InteropServices.GuidAttribute?displayProperty=nameWithType> attributes to the coclass interface. For additional information about how Tlbimp.exe imports interfaces and coclasses from a type library, see [Imported Type Conversion](https://learn.microsoft.com/en-us/)).  
-  
+      <format type="text/markdown"><![CDATA[
+
+## Remarks
+ You can apply this attribute to coclass interfaces, although the [Tlbimp.exe (Type Library Importer)](/dotnet/framework/tools/tlbimp-exe-type-library-importer) typically applies it for you when it imports a type library.
+
+ When Tlbimp.exe imports a coclass, it produces a managed class and an interface to represent the coclass. The coclass interface has the same interface identifier (IID) as the default interface of the original coclass. The imported coclass interface also retains the name of the coclass. Tlbimp.exe appends the original coclass name with "class" to identify the imported class.
+
+ You rarely apply this attribute. However, if you plan to write source code that produces metadata that closely simulates metadata produced by Tlbimp.exe, you should create a coclass interface for each coclass. Use the name of the original coclass to name the coclass interface and derive it from the default interface. In addition to the <xref:System.Runtime.InteropServices.CoClassAttribute>, you must also apply the <xref:System.Runtime.InteropServices.ComImportAttribute?displayProperty=nameWithType> and <xref:System.Runtime.InteropServices.GuidAttribute?displayProperty=nameWithType> attributes to the coclass interface.
+
  ]]></format>
     </remarks>
     <altmember cref="T:System.Runtime.InteropServices.ComImportAttribute" />

xml/System.Runtime.InteropServices/DispIdAttribute.xml

@@ -62,24 +62,20 @@
   <Docs>
     <summary>Specifies the COM dispatch identifier (DISPID) of a method, field, or property.</summary>
     <remarks>
-      <format type="text/markdown"><![CDATA[  
-  
-## Remarks  
- You can apply this attribute to methods, fields, or properties.  
-  
- This attribute contains the DISPID for the method, field, or property it describes. Unique DISPIDs are typically assigned by the common language runtime, but you can use this attribute to assign a specific DISPID to a method. When importing a type library, this attribute is applied to all methods with assigned DISPIDs. This ensures that any managed implementation of the same method retains the same DISPID if exposed to COM.  
-  
- See [DISPID Constants](https://learn.microsoft.com/en-us/).aspx) for a list of commonly used DISPID values.  
-  
-   
-  
-## Examples  
- The following example demonstrates how explicit DISPIDs can be assigned to members of a class.  
-  
+      <format type="text/markdown"><![CDATA[
+
+## Remarks
+ You can apply this attribute to methods, fields, or properties.
+
+ This attribute contains the DISPID for the method, field, or property it describes. Unique DISPIDs are typically assigned by the common language runtime, but you can use this attribute to assign a specific DISPID to a method. When importing a type library, this attribute is applied to all methods with assigned DISPIDs. This ensures that any managed implementation of the same method retains the same DISPID if exposed to COM.
+
+## Examples
+ The following example demonstrates how explicit DISPIDs can be assigned to members of a class.
+
  :::code language="cpp" source="~/snippets/cpp/VS_Snippets_CLR_Classic/classic DispIdAttribute Example/CPP/source.cpp" id="Snippet1":::
  :::code language="csharp" source="~/snippets/csharp/System.Runtime.InteropServices/DispIdAttribute/Overview/source.cs" id="Snippet1":::
- :::code language="vb" source="~/snippets/visualbasic/System.Runtime.InteropServices/DispIdAttribute/Overview/source.vb" id="Snippet1":::  
-  
+ :::code language="vb" source="~/snippets/visualbasic/System.Runtime.InteropServices/DispIdAttribute/Overview/source.vb" id="Snippet1":::
+
  ]]></format>
     </remarks>
   </Docs>

xml/System.Runtime.InteropServices/InterfaceTypeAttribute.xml

@@ -62,24 +62,22 @@
   <Docs>
     <summary>Indicates whether a managed interface is dual, dispatch-only, or <see langword="IUnknown" /> -only when exposed to COM.</summary>
     <remarks>
-      <format type="text/markdown"><![CDATA[  
-  
-## Remarks  
- You can apply this attribute to interfaces.  
-  
- By default, the [Tlbexp.exe (Type Library Exporter)](/dotnet/framework/tools/tlbexp-exe-type-library-exporter) exposes a managed interface to COM as a dual interface, giving you the flexibility of late binding or the performance of early binding. The <xref:System.Runtime.InteropServices.ComInterfaceType> enumeration enables you to override the default behavior and specify late binding only or early binding only. For example, you can apply `InterfaceType (ComInterfaceType.InterfaceIsIDispatch)` to an interface to produce metadata to restrict callers to late binding only. Although interfaces that derive from the `IDispatch` interface are often dual, the `InterfaceIsIDispatch` enumeration member allows only late-bound calls to the interface methods. This attribute has no effect on the managed view of the interface. For additional information on how interfaces are exposed to COM, see [Exported Type Conversion](https://learn.microsoft.com/en-us/)).  
-  
- The [Tlbimp.exe (Type Library Importer)](/dotnet/framework/tools/tlbimp-exe-type-library-importer) also applies this attribute to imported, nondual interfaces; it applies the appropriate enumeration member to indicate that the interface is dispatch-only or `IUnknown` -only.  
-  
-   
-  
-## Examples  
- The following example shows how `InterfaceTypeAttribute` controls how the interface is exposed to COM.  
-  
+      <format type="text/markdown"><![CDATA[
+
+## Remarks
+ You can apply this attribute to interfaces.
+
+ By default, the [Tlbexp.exe (Type Library Exporter)](/dotnet/framework/tools/tlbexp-exe-type-library-exporter) exposes a managed interface to COM as a dual interface, giving you the flexibility of late binding or the performance of early binding. The <xref:System.Runtime.InteropServices.ComInterfaceType> enumeration enables you to override the default behavior and specify late binding only or early binding only. For example, you can apply `InterfaceType (ComInterfaceType.InterfaceIsIDispatch)` to an interface to produce metadata to restrict callers to late binding only. Although interfaces that derive from the `IDispatch` interface are often dual, the `InterfaceIsIDispatch` enumeration member allows only late-bound calls to the interface methods. This attribute has no effect on the managed view of the interface.
+
+ The [Tlbimp.exe (Type Library Importer)](/dotnet/framework/tools/tlbimp-exe-type-library-importer) also applies this attribute to imported, nondual interfaces; it applies the appropriate enumeration member to indicate that the interface is dispatch-only or `IUnknown` -only.
+
+## Examples
+ The following example shows how `InterfaceTypeAttribute` controls how the interface is exposed to COM.
+
  :::code language="cpp" source="~/snippets/cpp/VS_Snippets_CLR_Classic/classic InterfaceTypeAttribute Example/CPP/source.cpp" id="Snippet1":::
  :::code language="csharp" source="~/snippets/csharp/System.Runtime.InteropServices/InterfaceTypeAttribute/Overview/source.cs" id="Snippet1":::
- :::code language="vb" source="~/snippets/visualbasic/System.Runtime.InteropServices/InterfaceTypeAttribute/Overview/source.vb" id="Snippet1":::  
-  
+ :::code language="vb" source="~/snippets/visualbasic/System.Runtime.InteropServices/InterfaceTypeAttribute/Overview/source.vb" id="Snippet1":::
+
  ]]></format>
     </remarks>
     <altmember cref="T:System.Runtime.InteropServices.ComInterfaceType" />
@@ -146,11 +144,11 @@
         <param name="interfaceType">Describes how the interface should be exposed to COM clients.</param>
         <summary>Initializes a new instance of the <see cref="T:System.Runtime.InteropServices.InterfaceTypeAttribute" /> class with the specified <see cref="T:System.Runtime.InteropServices.ComInterfaceType" /> enumeration member.</summary>
         <remarks>
-          <format type="text/markdown"><![CDATA[  
-  
-## Remarks  
- This constructor takes an underlying 16-bit integer that represents each <xref:System.Runtime.InteropServices.ComInterfaceType> enumeration member. The [Tlbimp.exe (Type Library Importer)](/dotnet/framework/tools/tlbimp-exe-type-library-importer) uses this constructor.  
-  
+          <format type="text/markdown"><![CDATA[
+
+## Remarks
+ This constructor takes an underlying 16-bit integer that represents each <xref:System.Runtime.InteropServices.ComInterfaceType> enumeration member. The [Tlbimp.exe (Type Library Importer)](/dotnet/framework/tools/tlbimp-exe-type-library-importer) uses this constructor.
+
  ]]></format>
         </remarks>
         <related type="Article" href="/dotnet/framework/tools/tlbimp-exe-type-library-importer">Tlbimp.exe (Type Library Importer)</related>
@@ -201,11 +199,11 @@
         <param name="interfaceType">One of the <see cref="T:System.Runtime.InteropServices.ComInterfaceType" /> values that describes how the interface should be exposed to COM clients.</param>
         <summary>Initializes a new instance of the <see cref="T:System.Runtime.InteropServices.InterfaceTypeAttribute" /> class with the specified <see cref="T:System.Runtime.InteropServices.ComInterfaceType" /> enumeration member.</summary>
         <remarks>
-          <format type="text/markdown"><![CDATA[  
-  
-## Remarks  
- For readable code that is less prone to error, always use this constructor.  
-  
+          <format type="text/markdown"><![CDATA[
+
+## Remarks
+ For readable code that is less prone to error, always use this constructor.
+
  ]]></format>
         </remarks>
       </Docs>

xml/System.Runtime.InteropServices/PrimaryInteropAssemblyAttribute.xml

@@ -75,7 +75,7 @@
 
  To specify a primary interop assembly in managed source code, you must apply the <xref:System.Runtime.InteropServices.GuidAttribute?displayProperty=nameWithType> and <xref:System.Runtime.InteropServices.PrimaryInteropAssemblyAttribute> to the assembly at design time. The <xref:System.Runtime.InteropServices.GuidAttribute> on the primary interop assembly identifies the LIBID of the type library and the <xref:System.Runtime.InteropServices.PrimaryInteropAssemblyAttribute> identifies the version of the particular type library for which this assembly is the primary interop assembly. The <xref:System.Runtime.InteropServices.PrimaryInteropAssemblyAttribute> can appear multiple times if the assembly is the primary interop assembly for multiple versions of the same type library.
 
- When using the types defined in a type library, always reference the primary interop assembly for that type library, rather than reimporting or redefining the types themselves. For guidelines and procedures on how to produce or use primary interop assemblies, see [Primary Interop Assemblies](https://learn.microsoft.com/en-us/)). For a detailed description of the type library importing process, see [Type Library to Assembly Conversion Summary](https://learn.microsoft.com/en-us/)).
+ When using the types defined in a type library, always reference the primary interop assembly for that type library, rather than reimporting or redefining the types themselves.
 
  ]]></format>
     </remarks>

xml/System.Text/Encoding.xml

@@ -4130,7 +4130,7 @@ In .NET 5 and later versions, the code page name `utf-7` is not supported.
 
  To calculate the exact array size required by <xref:System.Text.Encoding.GetBytes*> to store the resulting bytes, you should use the <xref:System.Text.Encoding.GetByteCount*> method. To calculate the maximum array size, use the <xref:System.Text.Encoding.GetMaxByteCount*> method. The <xref:System.Text.Encoding.GetByteCount*> method generally allows allocation of less memory, while the <xref:System.Text.Encoding.GetMaxByteCount*> method generally executes faster.
 
- <xref:System.Text.Encoding.GetMaxByteCount*> retrieves a worst-case number, including the worst case for the currently selected <xref:System.Text.EncoderFallback>. If a fallback is chosen with a potentially large string, <xref:System.Text.Encoding.GetMaxByteCount*> retrieves large values, particularly in cases where the worst case for the encoding involves switching modes for every character. For example, this can happen for ISO-2022-JP. For more information, see the blog post "[What's with Encoding.GetMaxByteCount() and Encoding.GetMaxCharCount()?](https://learn.microsoft.com/en-us/archive/blogs/shawnste/whats-with-encoding-getmaxbytecount-and-encoding-getmaxcharcount).
+ <xref:System.Text.Encoding.GetMaxByteCount*> retrieves a worst-case number, including the worst case for the currently selected <xref:System.Text.EncoderFallback>. If a fallback is chosen with a potentially large string, <xref:System.Text.Encoding.GetMaxByteCount*> retrieves large values, particularly in cases where the worst case for the encoding involves switching modes for every character. For example, this can happen for ISO-2022-JP. For more information, see the blog post "[What's with Encoding.GetMaxByteCount() and Encoding.GetMaxCharCount()?](https://learn.microsoft.com/archive/blogs/shawnste/whats-with-encoding-getmaxbytecount-and-encoding-getmaxcharcount).
 
  In most cases, this method retrieves reasonable values for small strings. For large strings, you might have to choose between using very large buffers and catching errors in the rare case when a more reasonable buffer is too small. You might also want to consider a different approach using <xref:System.Text.Encoding.GetByteCount*> or <xref:System.Text.Encoder.Convert*?displayProperty=nameWithType>.
 

xml/System.Threading/Lock.xml

@@ -32,7 +32,7 @@ It is recommended to use the <xref:System.Threading.Lock.EnterScope*> method wit
 
 :::code language="csharp" source="~/snippets/csharp/System.Threading/Lock/Overview/UsagePatterns.cs" id="Snippet1":::
 
-When using the C# `lock` keyword or similar to enter and exit a lock, the type of the expression must be precisely `System.Threading.Lock`. If the type of the expression is anything else, such as `Object` or a generic type like `T`, a different implementation that is not interchangeable can be used instead (such as <xref:System.Threading.Monitor>). For more information, see the relevant [compiler speclet](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-13.0/lock-object).
+When using the C# `lock` keyword or similar to enter and exit a lock, the type of the expression must be precisely `System.Threading.Lock`. If the type of the expression is anything else, such as `Object` or a generic type like `T`, a different implementation that is not interchangeable can be used instead (such as <xref:System.Threading.Monitor>). For more information, see the relevant [compiler speclet](https://learn.microsoft.com/dotnet/csharp/language-reference/proposals/csharp-13.0/lock-object).
 
 <xref:System.Threading.Thread.Interrupt*> can interrupt threads that are waiting to enter a lock. On Windows STA threads, waits for locks allow message pumping that can run other code on the same thread during a wait. Some features of the waits can be overridden by a custom <xref:System.Threading.SynchronizationContext>.