Merge pull request #10827 from dotnet/main

Merge main into live

Author: dotnet-policy-service[bot]

snippets/csharp/System.IO/FileInfo/OpenWrite/file openwrite.cs

@@ -34,18 +34,5 @@ public static void Main()
     }
 }
 //This code produces output similar to the following;
-//results may vary based on the computer/file structure/etc.:
-//
 //This is to test the OpenWrite method.
-//
-//
-//
-//
-//
-//
-//
-//
-//
-//
-//
 // </Snippet1>

xml/System.IO/FileInfo.xml

@@ -2137,7 +2137,7 @@ The following example demonstrates moving a file to a different location and ren
           <format type="text/markdown"><![CDATA[
 
 ## Remarks
- The <xref:System.IO.FileInfo.OpenWrite%2A> method opens a file if one already exists for the file path, or creates a new file if one does not exist. For an existing file, it does not append the new text to the existing text. Instead, it overwrites the existing characters with the new characters. If you overwrite a longer string (such as "This is a test of the OpenWrite method") with a shorter string (like "Second run"), the file will contain a mix of the strings ("Second runtest of the OpenWrite method").
+ The <xref:System.IO.FileInfo.OpenWrite%2A> method opens a file if one already exists for the file path, or creates a new file if one does not exist. For an existing file, it does not append the new text to the existing text. Instead, it overwrites the existing characters with the new characters. If you overwrite a longer string (such as "This is a test of the OpenWrite method") with a shorter string (like "Second run"), the file will contain a mix of the strings ("Second run test of the OpenWrite method.").
 
 
 

xml/System.Net.Mail/SmtpClient.xml

@@ -58,51 +58,45 @@
     </Attribute>
   </Attributes>
   <Docs>
-    <summary>Allows applications to send email by using the Simple Mail Transfer Protocol (SMTP). The <see cref="T:System.Net.Mail.SmtpClient" /> type is obsolete on some platforms and not recommended on others; for more information, see the Remarks section.</summary>
+    <summary>Sends email by using the Simple Mail Transfer Protocol (SMTP). The <see cref="T:System.Net.Mail.SmtpClient" /> type is not recommended for new development; for more information, see the Remarks section.</summary>
     <remarks>
-      <format type="text/markdown"><![CDATA[  
-  
-## Remarks
+      <format type="text/markdown"><![CDATA[
 
 The `SmtpClient` class is used to send email to an SMTP server for delivery. The SMTP protocol is defined in RFC 2821, which is available at [https://www.ietf.org](https://www.ietf.org/).  
 
 > [!IMPORTANT]
-> We don't recommend that you use the `SmtpClient` class for new development because `SmtpClient` doesn't support many modern protocols. Use [MailKit](https://github.com/jstedfast/MailKit) or other libraries instead. For more information, see [SmtpClient shouldn't be used](https://github.com/dotnet/platform-compat/blob/master/docs/DE0005.md) on GitHub.
+> We don't recommend that you use the `SmtpClient` class for new development because `SmtpClient` doesn't support many modern protocols. Use [MailKit](https://github.com/jstedfast/MailKit) or other libraries instead. For more information, see [SmtpClient shouldn't be used](https://github.com/dotnet/platform-compat/blob/master/docs/DE0005.md).
 
-The `SmtpClient` class is obsolete in Xamarin. However:
+The `SmtpClient` class is:
 
-- It is included in the .NET Standard 2.0 and later versions and therefore must be part of any .NET implementation that supports those versions.
-- It is present and can be used in .NET Framework 4 through .NET Framework 4.8.
-- It is usable in .NET Core, but its use isn't recommended.
+- Included in .NET Standard 2.0 and later versions and therefore must be part of any .NET implementation that supports those versions.
+- Present and can be used in .NET Framework 4 through .NET Framework 4.8.
+- Usable in .NET (Core), but its use isn't recommended.
 
 The classes shown in the following table are used to construct email messages that can be sent using <xref:System.Net.Mail.SmtpClient>.  
   
-|Class|Description|  
-|-----------|-----------------|  
-|<xref:System.Net.Mail.Attachment>|Represents file attachments. This class allows you to attach files, streams, or text to an email message.|  
-|<xref:System.Net.Mail.MailAddress>|Represents the email address of the sender and recipients.|  
-|<xref:System.Net.Mail.MailMessage>|Represents an email message.|  
+| Class                              | Description                                                |
+|------------------------------------|------------------------------------------------------------|
+| <xref:System.Net.Mail.Attachment>  | Represents file attachments. This class allows you to attach files, streams, or text to an email message. |
+| <xref:System.Net.Mail.MailAddress> | Represents the email address of the sender and recipients. |
+| <xref:System.Net.Mail.MailMessage> | Represents an email message.                               | 
   
  To construct and send an email message by using <xref:System.Net.Mail.SmtpClient>, you must specify the following information:  
   
--   The SMTP host server that you use to send email. See the <xref:System.Net.Mail.SmtpClient.Host%2A> and <xref:System.Net.Mail.SmtpClient.Port%2A> properties.  
-  
--   Credentials for authentication, if required by the SMTP server. See the <xref:System.Net.Mail.SmtpClient.Credentials%2A> property.  
-  
--   The email address of the sender. See the <xref:System.Net.Mail.SmtpClient.Send%2A> and <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods that take a `from` parameter. Also see the <xref:System.Net.Mail.MailMessage.From%2A?displayProperty=nameWithType> property.  
-  
--   The email address or addresses of the recipients. See the <xref:System.Net.Mail.SmtpClient.Send%2A> and <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods that take a `recipient` parameter. Also see the <xref:System.Net.Mail.MailMessage.To%2A?displayProperty=nameWithType> property.  
-  
--   The message content. See the <xref:System.Net.Mail.SmtpClient.Send%2A> and <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods that take a `body` parameter. Also see the <xref:System.Net.Mail.MailMessage.Body%2A?displayProperty=nameWithType> property.  
-  
- To include an attachment with an email message, first create the attachment by using the <xref:System.Net.Mail.Attachment> class, and then add it to the message by using the <xref:System.Net.Mail.MailMessage.Attachments%2A?displayProperty=nameWithType> property. Depending on the email reader used by the recipients and the file type of the attachment, some recipients might not be able to read the attachment. For clients that cannot display the attachment in its original form, you can specify alternate views by using the <xref:System.Net.Mail.MailMessage.AlternateViews%2A?displayProperty=nameWithType> property.  
+- The SMTP host server that you use to send email. See the <xref:System.Net.Mail.SmtpClient.Host%2A> and <xref:System.Net.Mail.SmtpClient.Port%2A> properties.  
+- Credentials for authentication, if required by the SMTP server. See the <xref:System.Net.Mail.SmtpClient.Credentials%2A> property.  
+- The email address of the sender. See the <xref:System.Net.Mail.SmtpClient.Send%2A> and <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods that take a `from` parameter. Also see the <xref:System.Net.Mail.MailMessage.From%2A?displayProperty=nameWithType> property.  
+- The email address or addresses of the recipients. See the <xref:System.Net.Mail.SmtpClient.Send%2A> and <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods that take a `recipient` parameter. Also see the <xref:System.Net.Mail.MailMessage.To%2A?displayProperty=nameWithType> property.  
+- The message content. See the <xref:System.Net.Mail.SmtpClient.Send%2A> and <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods that take a `body` parameter. Also see the <xref:System.Net.Mail.MailMessage.Body%2A?displayProperty=nameWithType> property.
+
+To include an attachment with an email message, first create the attachment by using the <xref:System.Net.Mail.Attachment> class, and then add it to the message by using the <xref:System.Net.Mail.MailMessage.Attachments%2A?displayProperty=nameWithType> property. Depending on the email reader used by the recipients and the file type of the attachment, some recipients might not be able to read the attachment. For clients that cannot display the attachment in its original form, you can specify alternate views by using the <xref:System.Net.Mail.MailMessage.AlternateViews%2A?displayProperty=nameWithType> property.  
   
  In .NET Framework, you can use the application or machine configuration files to specify default host, port, and credentials values for all <xref:System.Net.Mail.SmtpClient> objects. For more information, see [&lt;mailSettings&gt; Element (Network Settings)](/dotnet/framework/configure-apps/file-schema/network/mailsettings-element-network-settings). .NET Core does not support setting defaults. As a workaround, you must set the relevant properties on <xref:System.Net.Mail.SmtpClient> directly.  
   
  To send the email message and block while waiting for the email to be transmitted to the SMTP server, use one of the synchronous <xref:System.Net.Mail.SmtpClient.Send%2A> methods. To allow your program's main thread to continue executing while the email is transmitted, use one of the asynchronous <xref:System.Net.Mail.SmtpClient.SendAsync%2A> methods. The <xref:System.Net.Mail.SmtpClient.SendCompleted> event is raised when a <xref:System.Net.Mail.SmtpClient.SendAsync%2A> operation completes. To receive this event, you must add a <xref:System.Net.Mail.SendCompletedEventHandler> delegate to <xref:System.Net.Mail.SmtpClient.SendCompleted>. The <xref:System.Net.Mail.SendCompletedEventHandler> delegate must reference a callback method that handles notification of <xref:System.Net.Mail.SmtpClient.SendCompleted> events. To cancel an asynchronous email transmission, use the <xref:System.Net.Mail.SmtpClient.SendAsyncCancel%2A> method.  
   
 > [!NOTE]
->  If there is an email transmission in progress and you call <xref:System.Net.Mail.SmtpClient.SendAsync%2A> or <xref:System.Net.Mail.SmtpClient.Send%2A> again, you will receive an <xref:System.InvalidOperationException>.  
+> If there is an email transmission in progress and you call <xref:System.Net.Mail.SmtpClient.SendAsync%2A> or <xref:System.Net.Mail.SmtpClient.Send%2A> again, you will receive an <xref:System.InvalidOperationException>.  
   
  The connection established by the current instance of the <xref:System.Net.Mail.SmtpClient> class to the SMTP server may be re-used if an application wishes to send multiple messages to the same SMTP server. This is particularly useful when authentication or encryption are used establish a connection to the SMTP server. The process of authenticating and establishing a TLS session can be expensive operations. A requirement to re-establish a connection for each message when sending a large quantity of email to the same SMTP server could have a significant impact on performance. There are a number of high-volume email applications that send email status updates, newsletter distributions, or email alerts. Also many email client applications support an off-line mode where users can compose many email messages that are sent later when a connection to the SMTP server is established. It is typical for an email client to send all SMTP messages to a specific SMTP server (provided by the Internet service provider) that then forwards this email to other SMTP servers.  
   
@@ -112,12 +106,11 @@ The classes shown in the following table are used to construct email messages th
   
  The <xref:System.Net.Mail.SmtpClient> class has no `Finalize` method, so an application must call <xref:System.Net.Mail.SmtpClient.Dispose%2A> to explicitly free up resources. The <xref:System.Net.Mail.SmtpClient.Dispose%2A> method iterates through all established connections to the SMTP server specified in the <xref:System.Net.Mail.SmtpClient.Host%2A> property and sends a QUIT message followed by gracefully ending the TCP connection. The <xref:System.Net.Mail.SmtpClient.Dispose%2A> method also releases the unmanaged resources used by the <xref:System.Net.Sockets.Socket> and optionally disposes of the managed resources.  
   
- Call <xref:System.Net.Mail.SmtpClient.Dispose%2A> when you are finished using the <xref:System.Net.Mail.SmtpClient>. The <xref:System.Net.Mail.SmtpClient.Dispose%2A> method leaves the <xref:System.Net.Mail.SmtpClient> in an unusable state. After calling <xref:System.Net.Mail.SmtpClient.Dispose%2A>, you must release all references to the <xref:System.Net.Mail.SmtpClient> so the garbage collector can reclaim the memory that the <xref:System.Net.Mail.SmtpClient> was occupying.  
-  
-   
-  
+ Call <xref:System.Net.Mail.SmtpClient.Dispose%2A> when you are finished using the <xref:System.Net.Mail.SmtpClient>. The <xref:System.Net.Mail.SmtpClient.Dispose%2A> method leaves the <xref:System.Net.Mail.SmtpClient> in an unusable state. After calling <xref:System.Net.Mail.SmtpClient.Dispose%2A>, you must release all references to the <xref:System.Net.Mail.SmtpClient> so the garbage collector can reclaim the memory that the <xref:System.Net.Mail.SmtpClient> was occupying.
+
 ## Examples  
- The following code example demonstrates sending an email message asynchronously.  
+
+The following code example demonstrates sending an email message asynchronously.  
   
  :::code language="cpp" source="~/snippets/cpp/VS_Snippets_Remoting/NclMailASync/cpp/mailasync.cpp" id="Snippet1":::
  :::code language="csharp" source="~/snippets/csharp/System.Net.Mail/MailAddress/.ctor/mailasync.cs" id="Snippet1":::

xml/System/GC.xml

@@ -126,13 +126,9 @@ The following example uses several GC methods to get generation and memory infor
           <format type="text/markdown"><![CDATA[
 
 ## Remarks
- In determining when to schedule garbage collection, the runtime takes into account how much managed memory is allocated. If a small managed object allocates a large amount of unmanaged memory, the runtime takes into account only the managed memory, and thus underestimates the urgency of scheduling garbage collection. The <xref:System.GC.AddMemoryPressure%2A> method informs the runtime of this additional pressure on system memory.
+ The common pattern for releasing native resources is via a type's finalizer. If a managed object uses native memory, it can free that native memory in its finalizer. The garbage collector only knows about managed memory and schedules collections based on this knowledge. Imagine a scenario where a small managed object is associated with a large amount of native memory usage, and this managed object now lives in gen2. A gen2 GC might not happen for some time, which means the large amount of native memory won't be released until the next gen2 happens. The runtime provides the <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods to help with this scenario. The runtime keeps an internal record of how much memory pressure these APIs added and removed, and triggers a gen2 GC if deemed productive. So this is not a feature of the GC but rather something that the runtime provides to trigger GCs.
 
- The <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods improve performance only for types that exclusively depend on finalizers to release the unmanaged resources. It's not necessary to use these methods in types that follow the dispose pattern, where finalizers are used to clean up unmanaged resources only in the event that a consumer of the type forgets to call `Dispose`. For more information on object finalization and the dispose pattern, see [Cleaning Up Unmanaged Resources](/dotnet/standard/garbage-collection/unmanaged).
-
- In the simplest usage pattern, a managed object allocates unmanaged memory in the constructor and releases it in the `Finalize` method. Call the <xref:System.GC.AddMemoryPressure%2A> method after allocating the unmanaged memory, and call the <xref:System.GC.RemoveMemoryPressure%2A> method after releasing it.
-
- In more complicated scenarios, where the unmanaged memory allocation changes substantially during the lifetime of the managed object, you can call the <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods to communicate these incremental changes to the runtime.
+ If you have a convenient place to call these APIs, you don't necessarily have to use a finalizer. For example, if you know you can release the native memory when a specific method on the type is called, you can call the <xref:System.GC.RemoveMemoryPressure%2A> method at that point instead of having a finalizer.
 
 > [!CAUTION]
 >  You must ensure that you remove exactly the amount of pressure you add. Failing to do so can adversely affect the performance of the system in applications that run for long periods of time.
@@ -1701,13 +1697,9 @@ The following example demonstrates the use of the <xref:System.GC.GetGeneration%
           <format type="text/markdown"><![CDATA[
 
 ## Remarks
- In determining when to schedule garbage collection, the runtime takes into account how much managed memory is allocated. If a small managed object allocates a large amount of unmanaged memory, the runtime takes into account only the managed memory, and thus underestimates the urgency of scheduling garbage collection. The <xref:System.GC.AddMemoryPressure%2A> method informs the runtime of this additional pressure on system memory, and the <xref:System.GC.RemoveMemoryPressure%2A> method informs the runtime that the additional pressure has been released.
-
- The <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods improve performance only for types that exclusively depend on finalizers to release the unmanaged resources. It's not necessary to use these methods in types that follow the dispose pattern, where finalizers are used to clean up unmanaged resources only in the event that a consumer of the type forgets to call `Dispose`. For more information on object finalization and the dispose pattern, see [Cleaning Up Unmanaged Resources](/dotnet/standard/garbage-collection/unmanaged).
-
- In the simplest usage pattern, a managed object allocates unmanaged memory in the constructor and releases it in the `Finalize` method. Call the <xref:System.GC.AddMemoryPressure%2A> method after allocating the unmanaged memory, and call the <xref:System.GC.RemoveMemoryPressure%2A> method after releasing it.
+ The common pattern for releasing native resources is via a type's finalizer. If a managed object uses native memory, it can free that native memory in its finalizer. The garbage collector only knows about managed memory and schedules collections based on this knowledge. Imagine a scenario where a small managed object is associated with a large amount of native memory usage, and this managed object now lives in gen2. A gen2 GC might not happen for some time, which means the large amount of native memory won't be released until the next gen2 happens. The runtime provides the <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods to help with this scenario. The runtime keeps an internal record of how much memory pressure these APIs added and removed, and triggers a gen2 GC if deemed productive. So this is not a feature of the GC but rather something that the runtime provides to trigger GCs.
 
- In more complicated scenarios, where the unmanaged memory allocation changes substantially during the lifetime of the managed object, you can call the <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods to communicate these incremental changes to the runtime.
+ If you have a convenient place to call these APIs, you don't necessarily have to use a finalizer. For example, if you know you can release the native memory when a specific method on the type is called, you can call the <xref:System.GC.RemoveMemoryPressure%2A> method at that point instead of having a finalizer.
 
 > [!CAUTION]
 >  You must ensure that you remove exactly the amount of pressure you add. Failing to do so can adversely affect the performance of the system in applications that run for long periods of time.