Migrating master changes to 4.7.2 branch (#695)

Documentation/compatibility/ASPNET-accessibility-improvement.md

@@ -1,4 +1,4 @@
-## ASP.NET Accessibility Improvements in .NET 4.7.1
+## ASP.NET Accessibility Improvements in .NET Framework 4.7.1
 
 ### Scope
 Minor
@@ -41,7 +41,7 @@ In order for the Visual Studio Designer to benefit from these changes, it must r
   <runtime>
     ...
     <!-- AppContextSwitchOverrides value attribute is in the form of `key1=true|false;key2=true|false`  -->
-    <AppContextSwitchOverrides value="...;Switch.UseLegacyAccessibilityFeatures=false" />
+    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
     ...
   </runtime>
 </configuration>

Documentation/compatibility/SerialPort-background-thread-exceptions.md

@@ -10,9 +10,9 @@ Minor
 NotPlanned
 
 ### Change Description
-Background threads created with <xref:System.IO.Ports.SerialPort> streams no longer terminate the process when OS exceptions are thrown.  
+Background threads created with <xref:System.IO.Ports.SerialPort> streams no longer terminate the process when OS exceptions are thrown. <br/> 
 
-In applications that target the .NET Framework 4.7 and earlier versions, a process is terminated when an operating system exception is thrown on a background thread created with a <xref:System.IO.Ports.SerialPort> stream.  
+In applications that target the .NET Framework 4.7 and earlier versions, a process is terminated when an operating system exception is thrown on a background thread created with a <xref:System.IO.Ports.SerialPort> stream. <br/> 
 
 In applications that target the .NET Framework 4.7.1 or a later version, background threads wait for OS events related to the active serial port and could crash in some cases, such as sudden removal of the serial port. 
 

Documentation/compatibility/ServiceBase-doesnt-propagate-OnStart-exceptions.md

@@ -13,15 +13,15 @@ NotPlanned
 
 ### Change Description
 
-In the .NET Framework 4.7 and earlier versions, exceptions thrown on service startup are not propagated to the caller of <xref:System.ServiceProcess.ServiceBase.Run%2A?displayProperty=nameWithType>.
+In the .NET Framework 4.7 and earlier versions, exceptions thrown on service startup are not propagated to the caller of <xref:System.ServiceProcess.ServiceBase.Run%2A?displayProperty=nameWithType>.<br/>
 
 Starting with applications that target the .NET Framework 4.7.1, the runtime propagates exceptions to <xref:System.ServiceProcess.ServiceBase.Run%2A?displayProperty=nameWithType> for services that fail to start.
 
 - [x] Quirked
 - [ ] Build-time break
 
 ### Recommended Action
-On service start, if there is an exception, that exception will be propagated. This should help diagnose cases where services fail to start.
+On service start, if there is an exception, that exception will be propagated. This should help diagnose cases where services fail to start. <br/>
 
 If this behavior is undesirable, you can opt out of it by adding the following <AppContextSwitchOverrides> element to the <runtime> section of your application configuration file:
 

Documentation/compatibility/a-concurrentdictionary-serialized-in-_net-4_5-with-netdatacontractserializer-cannot-be-deserialized-by-_net-4_5_1-or-4_5_2.md

@@ -1,4 +1,4 @@
-## A ConcurrentDictionary serialized in .NET 4.5 with NetDataContractSerializer cannot be deserialized by .NET 4.5.1 or 4.5.2
+## A ConcurrentDictionary serialized in .NET Framework 4.5 with NetDataContractSerializer cannot be deserialized by .NET Framework 4.5.1 or 4.5.2
 
 ### Scope
 Minor

Documentation/compatibility/application_filtermessage-no-longer-throws-for-re-entrant-implementations-of-imessagefilter_prefiltermessage.md

@@ -20,7 +20,7 @@ which called
 or <xref:System.Windows.Forms.Application.RemoveMessageFilter(System.Windows.Forms.IMessageFilter)?displayProperty=name>
 (while also calling
 <xref:System.Windows.Forms.Application.DoEvents>)
-would cause an <xref:System.IndexOutOfRangeException?displayProperty=name>.
+would cause an <xref:System.IndexOutOfRangeException?displayProperty=name>.<p/>
 
 Beginning with applications targeting the .NET Framework 4.6.1, this exception is no longer thrown, and re-entrant filters as described above may be used.
 
@@ -38,7 +38,7 @@ Framework 4.6.1.
 
 Apps targeting the .NET Framework 4.6.1 can opt out of this change (or apps
 targeting older Frameworks may opt in) by using the
-[DontSupportReentrantFilterMessage](~/docs/framework/migration-guide/mitigation-custom-imessagefilter-prefiltermessage-implementations#mitigation)
+[DontSupportReentrantFilterMessage](~/docs/framework/migration-guide/mitigation-custom-imessagefilter-prefiltermessage-implementations.md#mitigation)
 compatibility switch.
 
 ### Affected APIs

Documentation/compatibility/binaryformatter-can-fail-to-find-type-from-loadfrom-context.md

@@ -29,12 +29,12 @@ when a type is being loaded from an assembly loaded in a different context, a
 ### Recommended Action
 If this exception is seen, the `Binder` property of the <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter?displayProperty=name> can be set to a custom binder that will find the correct type.
 
-```C#
+```csharp
 var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }
 ```
 
 And then the custom binder:
-```C#
+```csharp
 public class TypeFinderBinder : SerializationBinder
 {
 	private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

Documentation/compatibility/binding-a-wpf-selector-property-(such-as-'selecteditem')-to-a-static-property-does-not-work.md

@@ -19,7 +19,7 @@ In the .NET Framework 4.5, WPF Selector properties (such as 'SelectedItem' on <x
 - [ ] Build-time break
 
 ### Recommended Action
-This behavior was reverted in a servicing update for the .NET Framework 4.5. Please update the .NET Framework 4.5, or upgrade to .NET Framework 4.5.1 or later, to fix this issue.
+This behavior was reverted in a servicing update for the .NET Framework 4.5. To fix this issue, update the .NET Framework 4.5, or upgrade to .NET Framework 4.5.1 or later.
 
 ### Affected APIs
 * Not detectable via API analysis

Documentation/compatibility/change-in-behavior-for-task_waitall-methods-with-time-out-arguments.md

@@ -10,7 +10,7 @@ Minor
 Available
 
 ### Change Description
-Task.WaitAll behavior was made more consistent in .NET 4.5.
+<xref:System.Threading.Tasks.Task.WaitAll%2A?displayProperty=nameWithType> behavior was made more consistent in .NET Framework 4.5.
 
 In the .NET Framework 4, these methods behaved inconsistently. When the time-out
 expired, if one or more tasks were completed or canceled before the method call,
@@ -28,7 +28,7 @@ call) and no other tasks are still running.
 - [ ] Build-time break
 
 ### Recommended Action
-If an <xref:System.AggregateException?displayProperty=name> was being caught as a means of detecting a task that was cancelled prior to the WaitAll call being invoked, that code should instead do the same detection via the IsCanceled property (for example: .Any(t =&gt; t.IsCanceled)) since .NET 4.6 will only throw in that case if all awaited tasks are completed prior to the timeout.
+If an <xref:System.AggregateException?displayProperty=name> was being caught as a means of detecting a task that was cancelled prior to the <xref:System.Threading.Tasks.Task.WaitAll%2A> call being invoked, that code should instead do the same detection via the  <xref:System.Threading.Tasks.Task.IsCanceled%2A> property (for example: .Any(t =&gt; t.IsCanceled)) since .NET Framework 4.6 will only throw in that case if all awaited tasks are completed prior to the timeout.
 
 ### Affected APIs
 * `M:System.Threading.Tasks.Task.WaitAll(System.Threading.Tasks.Task[],System.Int32)`

Documentation/compatibility/change-in-behavior-in-data-definition-language-(ddl)-apis.md

@@ -12,17 +12,17 @@ Available
 ### Change Description
 The behavior of DDL APIs when AttachDBFilename is specified has changed as follows:
 * Connection strings need not specify an Initial Catalog value. Previously, both AttachDBFilename and Initial Catalog were required.
-* If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, the ObjectContext.DatabaseExists method returns true. Previously, it returned false.
-* If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, calling the ObjectContext.DeleteDatabase method deletes the files.
-* If ObjectContext.DeleteDatabase is called when the connection string specifies an AttachDBFilename value with an MDF that doesn't exist and an Initial Catalog that doesn't exist, the method throws an InvalidOperationException exception. Previously, it threw a SqlException exception.
+* If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, the <xref:System.Data.Objects.ObjectContext.DatabaseExists%2A> method returns `true`. Previously, it returned `false`.
+* If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, calling the <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> method deletes the files.
+* If <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> is called when the connection string specifies an AttachDBFilename value with an MDF that doesn't exist and an Initial Catalog that doesn't exist, the method throws an <xref:System.InvalidOperationException> exception. Previously, it threw a <xref:System.Data.SqlClient.SqlException> exception.
 
 - [ ] Quirked
 - [ ] Build-time break
 
 ### Recommended Action
 These changes make it easier to build tools and applications that use the DDL APIs. These changes can affect application compatibility in the following scenarios:
-- The user writes code that executes a DROP DATABASE command directly instead of calling ObjectContext.DeleteDatabase if ObjectContext.DatabaseExists returns true. This breaks existing code If the database is not attached but the MDF file exists.
-- The user writes code that expects the ObjectContext.DeleteDatabase method to throw a SqlException exception rather than an InvalidOperationException exception when the Initial Catalog and MDF file don't exist.
+- The user writes code that executes a `DROP DATABASE` command directly instead of calling <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> if <xref:System.Data.Objects.ObjectContext.DatabaseExists%2A> returns `true`. This breaks existing code If the database is not attached but the MDF file exists.
+- The user writes code that expects the <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> method to throw a <xref:System.Data.SqlClient.SqlException> rather than an <xref:System.InvalidOperationException> when the Initial Catalog and MDF file don't exist.
 
 ### Affected APIs
 * Not detectable via API analysis

Documentation/compatibility/change-in-path-separator-character-in-zip-files.md

@@ -10,7 +10,7 @@ Edge
 Planned
 
 ### Change Description
-For apps that target the .NET Framework 4.6.1 and later versions, the path separator character has changed from a backslash ("\") to a forward slash ("/") in the <xref:System.IO.Compression.ZipArchiveEntry.FullName> property of <xref:System.IO.Compression.ZipArchiveEntry>  objects created by overloads of the <xref:System.IO.Compression.ZipFile.CreateFromDirectory%2A> method. The change brings the .NET implementation into conformity with section 4.4.17.1 of the [.ZIP File Format Specification](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) and allows .ZIP archives to be decompressed on non-Windows systems.
+For apps that target the .NET Framework 4.6.1 and later versions, the path separator character has changed from a backslash ("\") to a forward slash ("/") in the <xref:System.IO.Compression.ZipArchiveEntry.FullName> property of <xref:System.IO.Compression.ZipArchiveEntry>  objects created by overloads of the <xref:System.IO.Compression.ZipFile.CreateFromDirectory%2A> method. The change brings the .NET implementation into conformity with section 4.4.17.1 of the [.ZIP File Format Specification](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) and allows .ZIP archives to be decompressed on non-Windows systems.<br />
 
 Decompressing a zip file created by an app that targets a previous version of the .NET Framework on non-Windows operating systems such as the Macintosh fails to preserve the directory structure. For example, on the Macintosh, it creates a set of files whose filename concatenates the directory path, along with any backslash ("\") characters, and the filename. As a result, the directory structure of decompressed files is not preserved.
 
@@ -20,17 +20,17 @@ Decompressing a zip file created by an app that targets a previous version of th
 
 ### Recommended Action
 
-The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework <xref:System.IO?displayProperty=nameWithType> namespace should be minimal, since these APIs can seamlessly handle either a slash ("/") or a backslash ("\\") as the path separator character.  
+The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework <xref:System.IO?displayProperty=nameWithType> namespace should be minimal, since these APIs can seamlessly handle either a slash ("`/`") or a backslash ("`\`") as the path separator character.<br />
 
-If this change is undesirable, you can opt out of it by adding a configuration setting to the [`<runtime>`](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/runtime-element.md) section of your application configuration file. The following example shows both the `<runtime` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-out switch:
+If this change is undesirable, you can opt out of it by adding a configuration setting to the [`<runtime>`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) section of your application configuration file. The following example shows both the `<runtime>` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-out switch:
 
 ```xml
 <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
 </runtime>
 ```
 
-In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the [`<runtime>`](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/runtime-element.md) section of the application configuration file. The following shows both the `<runtime>` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-in switch.
+In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the [`<runtime>`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) section of the application configuration file. The following shows both the `<runtime>` section and the `Switch.System.IO.Compression.ZipFile.UseBackslash` opt-in switch.
 
 ```xml
 <runtime>

Documentation/compatibility/changes-in-path-normalization.md

@@ -27,7 +27,7 @@ in path normalization are enabled by default:
 
 - The runtime defers to the operating system's [GetFullPathName](https://msdn.microsoft.com/library/windows/desktop/aa364963(v=vs.85).aspx) function to normalize paths.
 - Normalization no longer involves trimming the end of directory segments (such as a space at the end of a directory name).
-- Support for device path syntax in full trust, including `\\.\` and, for file I/O APIs in mscorlib.dll, '\\?\'.
+- Support for device path syntax in full trust, including <code>\\.\</code> and, for file I/O APIs in mscorlib.dll, <code>\\?\</code>.
 - The runtime does not validate device syntax paths.
 - The use of device syntax to access alternate data streams is supported.
 

Documentation/compatibility/clickonce-supports-sha-256-on-4_0-targeted-apps.md

@@ -11,8 +11,8 @@ Planned
 
 ### Change Description
 Previously, a ClickOnce app with a certificate signed with SHA-256 would require
-.NET 4.5 or later to be present, even if the app targeted 4.0. Now, 4.0-targeted
-ClickOnce apps can run on 4.0, even if signed with SHA-256.
+.NET Framework 4.5 or later to be present, even if the app targeted 4.0. Now, .NET Framework 4.0-targeted
+ClickOnce apps can run on .NET Framework 4.0, even if signed with SHA-256.
 
 - [ ] Quirked
 - [x] Build-time break

Documentation/compatibility/coerceisselectionboxhighlighted.md

@@ -20,7 +20,7 @@ and its data source can result in a <xref:System.NullReferenceException?displayP
 - [ ] Build-time break
 
 ### Recommended Action
-If possible, please upgrade to .NET 4.6.2.
+If possible, upgrade to .NET Framework 4.6.2.
 
 ### Affected APIs
 * `P:System.Windows.Controls.ComboBox.IsSelectionBoxHighlighted`

Documentation/compatibility/connection-pool-blocking-period-for-azure-sql-databases-is-removed.md

@@ -11,14 +11,14 @@ Investigating
 
 ### Change Description
 Starting with the .NET Framework 4.6.2, for connection open requests to known
-Azure SQL databases (*.database.windows.net, *.database.chinacloudapi.cn,
-*.database.usgovcloudapi.net, *.database.cloudapi.de), the connection pool
+Azure SQL databases (\*.database.windows.net, \*.database.chinacloudapi.cn,
+\*.database.usgovcloudapi.net, \*.database.cloudapi.de), the connection pool
 blocking period is removed, and connection open errors are not cached. Attempts
 to retry connection open requests will occur almost immediately after transient
 connection errors. This change allows the connection open attempt to be retried
 immediately for Azure SQL databases, thereby improving the performance of cloud-
 enabled apps. For all other connection attempts, the connection pool blocking
-period continues to be enforced.
+period continues to be enforced.<p/>
 
 In the .NET Framework 4.6.1 and earlier versions, when an app encounters a
 transient connection failure when connecting to a database, the connection

Documentation/compatibility/cspparameters_parentwindowhandle-now-expects-hwnd-value.md

@@ -20,7 +20,7 @@ Starting with apps that target the .NET Framework 4.7, a Windows Forms
 application can set the <xref:System.Security.Cryptography.CspParameters.ParentWindowHandle>
 property with code like the following:
 
-```C#
+```csharp
 cspParameters.ParentWindowHandle = form.Handle;
 ```
 
@@ -35,9 +35,9 @@ effect, but on Windows 8 and later versions, it results in a
 - [ ] Build-time break
 
 ### Recommended Action
-Applications targeting .NET 4.7 or higher wishing to register a parent window relationship are encouraged to use the simplified form:
+Applications targeting .NET Framework 4.7 or higher wishing to register a parent window relationship are encouraged to use the simplified form:
 
-```C#
+```csharp
 cspParameters.ParentWindowHandle = form.Handle;
 ```
 

Documentation/compatibility/currentculture-flows-across-tasks.md

@@ -39,13 +39,13 @@ as the first operation in an async Task. Alternatively, the old behavior (of not
 flowing <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name>/<xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name>)
 may be opted into by setting the following compatibility switch:
 
-```C#
+```csharp
 AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);
 ```
 
 This issue has been fixed by WPF in .NET Framework 4.6.2. It has also been fixed
 in .NET Frameworks 4.6, 4.6.1 through [KB 3139549](https://support.microsoft.com/kb/3139549).
-Applications targeting .NET 4.6 or later will automatically get the right
+Applications targeting .NET Framework 4.6 or later will automatically get the right
 behavior in WPF applications -
 <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name>/<xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name>)
 would be preserved across Dispatcher operations.

Documentation/compatibility/currentculture-not-preserved-across-wpf-dispatcher-operations.md

@@ -62,13 +62,13 @@ can be avoided by targeting the .NET Framework 4.5.2.
 Apps that target .NET Framework 4.6 or later can also work around this by
 setting the following compatibility switch:
 
-    ```
+    ```csharp
     AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);
     ```
 
 This issue has been fixed by WPF in .NET Framework 4.6.2. It has also been fixed
 in .NET Frameworks 4.6, 4.6.1 through [KB 3139549](https://support.microsoft.com/kb/3139549).
-Applications targeting .NET 4.6 or later will automatically
+Applications targeting .NET Framework 4.6 or later will automatically
 get the right behavior in WPF applications -
 <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name>/<xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name>)
 would be preserved across Dispatcher operations.

Documentation/compatibility/datagridcellspanel_bringintoview-throws-argumentoutofrangeexception.md

@@ -26,8 +26,8 @@ asynchronous work happens, an
 ### Recommended Action
 
 Any one of the following:
-1. Upgrade to .NET 4.7.
-2. Install the latest servicing patch for .NET 4.6.2.
+1. Upgrade to .NET Framework 4.7.
+2. Install the latest servicing patch for .NET Framework 4.6.2.
 3. Avoid removing columns until the asynchronous response to <xref:System.Windows.Controls.DataGrid.ScrollIntoView(System.Object)> has completed.
 
 ### Affected APIs