chore: cleanup includes/ (dotnet#15553)

Ran markdownlint --fix "includes/**/*.md" for MD009 and MD022

Author: nschonni

includes/compiler-options.md

@@ -1,2 +1,2 @@
 
-Every compiler option is available in two forms: **-option** and **/option**. The documentation only shows the -option form. 
+Every compiler option is available in two forms: **-option** and **/option**. The documentation only shows the -option form.

includes/core-changes/aspnetcore/3.0/authz-iauthzpolicyprovider-new-method.md

@@ -2,7 +2,7 @@
 
 In ASP.NET Core 3.0, a new `GetFallbackPolicyAsync` method was added to `IAuthorizationPolicyProvider`. This fallback policy is used by the authorization middleware when no policy is specified.
 
-For more information, see [aspnet/AspNetCore#9759](https://github.com/aspnet/AspNetCore/pull/9759). 
+For more information, see [aspnet/AspNetCore#9759](https://github.com/aspnet/AspNetCore/pull/9759).
 
 #### Version introduced
 

includes/core-changes/aspnetcore/3.0/caching-new-sqlclient-package.md

@@ -20,7 +20,7 @@ The `Microsoft.Extensions.Caching.SqlServer` package used the `System.Data.SqlCl
 
 #### Recommended action
 
-Customers shouldn't need to worry about this breaking change unless they were using types returned by the `Microsoft.Extensions.Caching.SqlServer` package and casting them to `System.Data.SqlClient` types. For example, if someone was casting a `DbConnection` to the [old SqlConnection type](xref:System.Data.SqlClient.SqlConnection), they would need to change the cast to the new `Microsoft.Data.SqlClient.SqlConnection` type. 
+Customers shouldn't need to worry about this breaking change unless they were using types returned by the `Microsoft.Extensions.Caching.SqlServer` package and casting them to `System.Data.SqlClient` types. For example, if someone was casting a `DbConnection` to the [old SqlConnection type](xref:System.Data.SqlClient.SqlConnection), they would need to change the cast to the new `Microsoft.Data.SqlClient.SqlConnection` type.
 
 #### Category
 

includes/core-changes/aspnetcore/3.0/http-defaulthttpcontext-extensibility-removed.md

@@ -2,7 +2,7 @@
 
 As part of ASP.NET Core 3.0 performance improvements, the extensibility of `DefaultHttpContext` was removed. The class is now `sealed`. For more information, see [aspnet/AspNetCore#6504](https://github.com/aspnet/AspNetCore/pull/6504).
 
-If your unit tests use `Mock<DefaultHttpContext>`, use `Mock<HttpContext>` instead. 
+If your unit tests use `Mock<DefaultHttpContext>`, use `Mock<HttpContext>` instead.
 
 For discussion, see [aspnet/AspNetCore#6534](https://github.com/aspnet/AspNetCore/issues/6534).
 
@@ -24,7 +24,7 @@ The extensibility was provided initially to allow pooling of the `HttpContext`,
 
 #### Recommended action
 
-If you're using `Mock<DefaultHttpContext>` in your unit tests, begin using `Mock<HttpContext>` instead. 
+If you're using `Mock<DefaultHttpContext>` in your unit tests, begin using `Mock<HttpContext>` instead.
 
 #### Category
 

includes/core-changes/aspnetcore/3.0/http-response-body-changes.md

@@ -24,7 +24,7 @@ The motivation is to combine the response body APIs into a single new feature in
 
 #### Recommended action
 
-Use `IHttpResponseBodyFeature` where you previously were using `IHttpResponseFeature.Body`, 
+Use `IHttpResponseBodyFeature` where you previously were using `IHttpResponseFeature.Body`,
 `IHttpSendFileFeature`, or `IHttpBufferingFeature`.
 
 #### Category
@@ -36,7 +36,7 @@ ASP.NET Core
 - <xref:Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature?displayProperty=nameWithType>
 - <xref:Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body?displayProperty=fullName>
 - <xref:Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature?displayProperty=nameWithType>
- 
+
 <!-- 
 
 #### Affected APIs

includes/core-changes/aspnetcore/3.0/http-synchronous-io-disabled.md

@@ -45,7 +45,7 @@ For discussion, see [aspnet/AspNetCore#7644](https://github.com/aspnet/AspNetCor
 
 #### New behavior
 
-These synchronous APIs are disallowed by default: 
+These synchronous APIs are disallowed by default:
 
 Expect errors similar to:
 

includes/core-changes/aspnetcore/3.0/mvc-action-async-suffix-trimmed.md

@@ -40,7 +40,7 @@ This change doesn't affect names specified using the `[ActionName]` attribute. T
 ```csharp
 services.AddMvc(options =>
 {
-   options.SuppressAsyncSuffixInActionNames = false; 
+   options.SuppressAsyncSuffixInActionNames = false;
 });
 ```
 
@@ -58,7 +58,7 @@ If your app depends on MVC actions preserving the name's `Async` suffix, choose
 ```csharp
 services.AddMvc(options =>
 {
-   options.SuppressAsyncSuffixInActionNames = false; 
+   options.SuppressAsyncSuffixInActionNames = false;
 });
 ```
 

includes/core-changes/aspnetcore/3.0/mvc-precompilation-tool-deprecated.md

@@ -2,7 +2,7 @@
 
 In ASP.NET Core 1.1, the `Microsoft.AspNetCore.Mvc.Razor.ViewCompilation` (MVC precompilation tool) package was introduced to add support for publish-time compilation of Razor files (*.cshtml* files). In ASP.NET Core 2.1, the [Razor SDK](/aspnet/core/razor-pages/sdk?view=aspnetcore-2.1) was introduced to expand upon features of the precompilation tool. The Razor SDK added support for build- and publish-time compilation of Razor files. The SDK verifies the correctness of *.cshtml* files at build time while improving on app startup time. The Razor SDK is on by default, and no gesture is required to start using it.
 
-In ASP.NET Core 3.0, the ASP.NET Core 1.1-era MVC precompilation tool was removed. Earlier package versions will continue receiving important bug and security fixes in the patch release. 
+In ASP.NET Core 3.0, the ASP.NET Core 1.1-era MVC precompilation tool was removed. Earlier package versions will continue receiving important bug and security fixes in the patch release.
 
 #### Version introduced
 

includes/core-changes/aspnetcore/3.0/session-obsolete-apis-removed.md

@@ -1,4 +1,4 @@
-### Session state: Obsolete APIs removed 
+### Session state: Obsolete APIs removed
 
 Obsolete APIs for configuring session cookies were removed. For more information, see [aspnet/Announcements#257](https://github.com/aspnet/Announcements/issues/257).
 

includes/core-changes/aspnetcore/3.0/sharedfx-app-shared-framework-assemblies.md

@@ -1,6 +1,6 @@
 ### Shared framework: Assemblies removed from Microsoft.AspNetCore.App
 
-Starting in ASP.NET Core 3.0, the ASP.NET Core shared framework (`Microsoft.AspNetCore.App`) only contains first-party assemblies that are fully developed, supported, and serviceable by Microsoft. 
+Starting in ASP.NET Core 3.0, the ASP.NET Core shared framework (`Microsoft.AspNetCore.App`) only contains first-party assemblies that are fully developed, supported, and serviceable by Microsoft.
 
 #### Change description
 

includes/core-changes/aspnetcore/3.0/signalr-successhandshakedata-replaced.md

@@ -1,6 +1,6 @@
 ### SignalR: HandshakeProtocol.SuccessHandshakeData replaced
 
-The [HandshakeProtocol.SuccessHandshakeData](https://github.com/aspnet/AspNetCore/blob/c5b2bc0df2a0027832bf7d01dfb19ca39cd08ae6/src/SignalR/common/SignalR.Common/src/Protocol/HandshakeProtocol.cs#L27) field was removed and replaced with a helper method that generates a successful handshake response given a specific `IHubProtocol`. 
+The [HandshakeProtocol.SuccessHandshakeData](https://github.com/aspnet/AspNetCore/blob/c5b2bc0df2a0027832bf7d01dfb19ca39cd08ae6/src/SignalR/common/SignalR.Common/src/Protocol/HandshakeProtocol.cs#L27) field was removed and replaced with a helper method that generates a successful handshake response given a specific `IHubProtocol`.
 
 #### Version introduced
 
@@ -12,7 +12,7 @@ The [HandshakeProtocol.SuccessHandshakeData](https://github.com/aspnet/AspNetCor
 
 #### New behavior
 
-`HandshakeProtocol.SuccessHandshakeData` has been replaced by a `static` `GetSuccessfulHandshake(IHubProtocol protocol)` method that returns a `ReadOnlyMemory<byte>` based on the specified protocol. 
+`HandshakeProtocol.SuccessHandshakeData` has been replaced by a `static` `GetSuccessfulHandshake(IHubProtocol protocol)` method that returns a `ReadOnlyMemory<byte>` based on the specified protocol.
 
 #### Reason for change
 

includes/core-changes/corefx/floating-point-parsing-does-not-overflow.md

@@ -8,7 +8,7 @@ In .NET Core 2.2 and earlier versions, the <xref:System.Double.Parse%2A?displayP
 
 Starting with .NET Core 3.0, the <xref:System.Double.Parse%2A?displayProperty=nameWithType>, <xref:System.Double.TryParse%2A?displayProperty=nameWithType>, <xref:System.Single.Parse%2A?displayProperty=nameWithType>, and <xref:System.Single.TryParse%2A?displayProperty=nameWithType> methods no longer fail when parsing out-of-range numeric strings. Instead, the <xref:System.Double> parsing methods return <xref:System.Double.PositiveInfinity?displayProperty=nameWithType> for values that exceed <xref:System.Double.MaxValue?displayProperty=nameWithType>, and they return <xref:System.Double.NegativeInfinity?displayProperty=nameWithType> for values that are less than <xref:System.Double.MinValue?displayProperty=nameWithType>. Similarly, the <xref:System.Single> parsing methods return <xref:System.Single.PositiveInfinity?displayProperty=nameWithType> for values that exceed <xref:System.Single.MaxValue?displayProperty=nameWithType>, and they return <xref:System.Single.NegativeInfinity?displayProperty=nameWithType> for values that are less than <xref:System.Single.MinValue?displayProperty=nameWithType>.
 
-This change was made for improved IEEE 754:2008 compliance. 
+This change was made for improved IEEE 754:2008 compliance.
 
 #### Version introduced
 

includes/core-changes/corefx/jsonfactoryconverter-createconverter.md

@@ -4,7 +4,7 @@ To facilitate the composition of <xref:System.Text.Json.Serialization.JsonConver
 
 #### Change description
 
-The signature of the `CreateConverter` method in .NET Core prior to version 3.0 Preview 8 was: 
+The signature of the `CreateConverter` method in .NET Core prior to version 3.0 Preview 8 was:
 
 ```csharp
 namespace System.Text.Json.Serialization

includes/core-changes/globalization/c-locale-maps-to-invariant-locale.md

@@ -1,12 +1,12 @@
 ### "C" locale maps to the invariant locale
 
-.NET Core 2.2 and earlier versions depend on the default ICU behavior, which maps the "C" locale to the en_US_POSIX locale. The en_US_POSIX locale has an undesirable collation behavior, because it doesn't support case-insensitive string comparisons. Because some Linux distributions set the "C" locale as the default locale, users were experiencing unexpected behavior. 
+.NET Core 2.2 and earlier versions depend on the default ICU behavior, which maps the "C" locale to the en_US_POSIX locale. The en_US_POSIX locale has an undesirable collation behavior, because it doesn't support case-insensitive string comparisons. Because some Linux distributions set the "C" locale as the default locale, users were experiencing unexpected behavior.
 
 #### Change description
 
 Starting with .NET Core 3.0, the "C" locale mapping has changed to use the Invariant locale instead of en_US_POSIX. The "C" locale to Invariant mapping is also applied to Windows for consistency.
 
-Mapping "C" to en_US_POSIX culture caused customer confusion, because en_US_POSIX doesn't support case insensitive sorting/searching string operations. Because the "C" locale is used as a default locale in some of the Linux distros, customers experienced this undesired behavior on these operating systems. 
+Mapping "C" to en_US_POSIX culture caused customer confusion, because en_US_POSIX doesn't support case insensitive sorting/searching string operations. Because the "C" locale is used as a default locale in some of the Linux distros, customers experienced this undesired behavior on these operating systems.
 
 #### Version introduced
 
@@ -18,7 +18,7 @@ Nothing specific more than the awareness of this change. This change affects onl
 
 ### Category
 
-Globalization 
+Globalization
 
 ### Affected APIs
 

includes/core-changes/networking/httprequestmessage-version-change.md

@@ -1,4 +1,4 @@
-### Default value of HttpRequestMessage.Version changed to 1.1 
+### Default value of HttpRequestMessage.Version changed to 1.1
 
 The default value of the <xref:System.Net.Http.HttpRequestMessage.Version?displayProperty=fullName> property has changed from 2.0 to 1.1.
 
@@ -8,10 +8,10 @@ The default value of the <xref:System.Net.Http.HttpRequestMessage.Version?displa
 
 #### Change description
 
-In .NET Core 1.0 through 2.0, the default value of the <xref:System.Net.Http.HttpRequestMessage.Version?displayProperty=fullName> property is 1.1. Starting with .NET Core 2.1, it was changed to 2.1. 
+In .NET Core 1.0 through 2.0, the default value of the <xref:System.Net.Http.HttpRequestMessage.Version?displayProperty=fullName> property is 1.1. Starting with .NET Core 2.1, it was changed to 2.1.
 
 Starting with .NET Core 3.0, the default version number returned by the <xref:System.Net.Http.HttpRequestMessage.Version?displayProperty=fullName> property is once again 1.1.
- 
+
 #### Recommended action
 
 Update your code if it depends on the <xref:System.Net.Http.HttpRequestMessage.Version?displayProperty=fullName> property returning a default value of 2.0.

includes/core-changes/versionselector.md

@@ -6,7 +6,7 @@
 > - [(3.0 Preview 7| 3.0 Preview 8)](~/docs/core/compatibility/3.0.7-3.0.8.md)
 > - [(3.0 Preview 8| 3.0 Preview 9)](~/docs/core/compatibility/3.0.8-3.0.9.md)
 > - [(3.0 Preview 9| 3.0 RC1)](~/docs/core/compatibility/3.0.9-3.0rc1.md)
-> 
+
 <!--
 
 > - [(2.2 | 3.0 Preview 7)](~/docs/core/compatibility/2.2-3.0.7.md)

includes/core-changes/visualbasic/microsoft.visualbasic.applicationservices-unavailable.md

@@ -11,7 +11,7 @@ The types in the <xref:Microsoft.VisualBasic.ApplicationServices?displayProperty
 The types in the <xref:Microsoft.VisualBasic.ApplicationServices?displayProperty=fullName> namespace were available in some .NET Core 3.0 Preview releases. They are no longer available starting with .NET Core 3.0 Preview 9.
 
 The types were removed to avoid unnecessary assembly dependencies or breaking changes in subsequent releases.
- 
+
 #### Recommended action
 
 If your code depends on the use of <xref:Microsoft.VisualBasic.ApplicationServices> types and their members, you may be able to use a corresponding type or member in the .NET class library. For example, some <xref:System.Environment?displayProperty=nameWithType> and <xref:System.Security.Principal.WindowsIdentity?displayProperty=nameWithType> members provide equivalent functionality to the properties of the <xref:Microsoft.VisualBasic.ApplicationServices.User?displayProperty=nameWithType> class.

includes/core-changes/visualbasic/microsoft.visualbasic.devices-unavailable.md

@@ -11,7 +11,7 @@ The types in the <xref:Microsoft.VisualBasic.Devices?displayProperty=fullName> n
 The types in the <xref:Microsoft.VisualBasic.Devices?displayProperty=fullName> namespace were available in some .NET Core 3.0 Preview releases,. They are no longer available starting with .NET Core 3.0 Preview 9.
 
 The types were removed to avoid unnecessary assembly dependencies or breaking changes in subsequent releases.
- 
+
 #### Recommended action
 
 If your code depends on the use of <xref:Microsoft.VisualBasic.Devices> types and their members, you may be able to use a corresponding type or member in the .NET class library. For example, equivalent functionality to the <xref:Microsoft.VisualBasic.Devices.Clock?displayProperty=nameWithType> class is provided by the <xref:System.DateTime?displayProperty=nameWithType> and <xref:System.Environment?displayProperty=nameWithType> types, and equivalent functionality to the <xref:Microsoft.VisualBasic.Devices.Ports?displayProperty=nameWithType> class is provided by types in the <xref:System.IO.Ports?displayProperty=nameWithType> namespace.

includes/core-changes/visualbasic/microsoft.visualbasic.myservices-unavailable.md

@@ -11,14 +11,14 @@ The types in the <xref:Microsoft.VisualBasic.MyServices?displayProperty=fullName
 The types in the <xref:Microsoft.VisualBasic.MyServices?displayProperty=fullName> namespace were available in some .NET Core 3.0 Preview releases. They are no longer available starting with .NET Core 3.0 Preview 9.
 
 The types were removed to avoid unnecessary assembly dependencies or breaking changes in subsequent releases.
- 
+
 #### Recommended action
 
 If your code depends on the use of **Microsoft.VisualBasic.MyServices** types and their members, there are corresponding types and members in the .NET class library. The following is a mapping of  **Microsoft.VisualBasic.MyServices** types to their equivalent .NET class library types:
 
 |Microsoft.VisualBasic.MyServices type|.NET class library type|
 |--|--|
-|<xref:Microsoft.VisualBasic.MyServices.ClipboardProxy>|<xref:System.Windows.Clipboard?displayProperty=nameWithType> for WPF applications, <xref:System.Windows.Forms.Clipboard?displayProperty=nameWithType> for Windows Forms applications| 
+|<xref:Microsoft.VisualBasic.MyServices.ClipboardProxy>|<xref:System.Windows.Clipboard?displayProperty=nameWithType> for WPF applications, <xref:System.Windows.Forms.Clipboard?displayProperty=nameWithType> for Windows Forms applications|
 |<xref:Microsoft.VisualBasic.MyServices.FileSystemProxy>|Types in the <xref:System.IO> namespace|
 |<xref:Microsoft.VisualBasic.MyServices.RegistryProxy>|Registry-related types in the <xref:Microsoft.Win32> namespace|
 |<xref:Microsoft.VisualBasic.MyServices.SpecialDirectoriesProxy>|<xref:System.Environment.GetFolderPath%2A?displayProperty=nameWithType>|

includes/core-changes/windowsforms/deprecate-enablevisualstylevalidation.md

@@ -4,7 +4,7 @@ The `Switch.System.Windows.Forms.EnableVisualStyleValidation` compatibility swit
 
 #### Change description
 
-In .NET Framework, the `Switch.System.Windows.Forms.EnableVisualStyleValidation` compatibility switch allowed an application to opt out of validation of visual styles supplied in a numeric form. 
+In .NET Framework, the `Switch.System.Windows.Forms.EnableVisualStyleValidation` compatibility switch allowed an application to opt out of validation of visual styles supplied in a numeric form.
 
 In .NET Core, the `Switch.System.Windows.Forms.EnableVisualStyleValidation` switch is not supported.
 

includes/csharp-interactive-with-utc-partial-note.md

@@ -1,5 +1,5 @@
 
 > [!NOTE]
-> Some of the C# examples in this article run in the [Try.NET](https://dotnet.microsoft.com/platform/try-dotnet) inline code runner and playground. Select the **Run** button to run an example in an interactive window. Once you execute the code, you can modify it and run the modified code by selecting **Run** again. The modified code either runs in the interactive window or, if compilation fails, the interactive window displays all C# compiler error messages. 
->  
+> Some of the C# examples in this article run in the [Try.NET](https://dotnet.microsoft.com/platform/try-dotnet) inline code runner and playground. Select the **Run** button to run an example in an interactive window. Once you execute the code, you can modify it and run the modified code by selecting **Run** again. The modified code either runs in the interactive window or, if compilation fails, the interactive window displays all C# compiler error messages.
+>
 > The [local time zone](xref:System.TimeZoneInfo.Local) of the [Try.NET](https://dotnet.microsoft.com/platform/try-dotnet) inline code runner and playground is Coordinated Universal Time, or UTC. This may affect the behavior and the output of examples that illustrate the <xref:System.DateTime>, <xref:System.DateTimeOffset>, and <xref:System.TimeZoneInfo> types and their members.

includes/migration-guide/retargeting/introduction.md

@@ -1,4 +1,5 @@
 ## Introduction
+
 Retargeting changes affect apps that are recompiled to target a different .NET Framework. They include:
 
 * Changes in the design-time environment. For example, build tools may emit warnings when previously they did not.

includes/migration-guide/runtime/introduction.md

@@ -1,4 +1,5 @@
 ## Introduction
+
 Runtime changes affect all apps that are running under a .NET Framework it was not compiled against and that use a particular feature.
 
 In the topics that describe runtime changes, we have classified individual items by their expected impact, as follows: