daohualiuxiang
/
dotnet
mirror of https://github.com/microsoft/dotnet.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Changes to parallel changes to dotnet/docs repo (#512)

pull/519/head
Ron Petrusha 2017-10-16 15:19:46 -07:00 committed by GitHub
parent a658237876
commit ad03ad5a55
14 changed files with 66 additions and 101 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
Documentation/compatibility/ASPNET Accessibility Improvement.md
View File

@ -1,50 +0,0 @@
## ASP.NET Accessibility Improvement in .NET 4.7.1
### Scope
Minor
### Version Introduced
4.7.1
### Source Analyzer Status
NotPlanned
### Change Description
ASP.NET is improving how ASP.NET Web Controls work with accessibility technology in Visual Studio to better support ASP.NET customers. These include the following changes:
- Changes to implement missing UI accessibility patterns in controls, like the Add Field dialog in the Details View wizard.
- Changes to improve the display in High Contrast mode, like the Data Pager Fields Editor.
- Changes to improve the keyboard navigation experiences for controls, like the Configure Object Context Window or the Configure Data Source Window.
- [x] Quirked
- [ ] Build-time break
### Recommended Action
__How to opt in or out of these changes__
In order for the Visual Studio Designer to benefit from these changes, it must run on the .NET Framework 4.7.1 or later. The web application can benefit from these changes in either of the following ways:
- Install Visual Studio 2017 15.3 or later, which supports the new accessibility features with the following AppContext Switch by default.
- Opt out of the legacy accessibility behaviors by adding the __Switch.UseLegacyAccessibility__ AppContext Switch to the ```<runtime>``` section in the devenv.exe.config file and setting it to ```false```, as the following example shows.
```
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true|false;key2=true|false -->
<AppContextSwitchOverrides value="...;Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>
```
Applications that target the .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to ```true```.
### Affected APIs
* Not detectable via API analysis
### Category
ASP.NET

32
Documentation/compatibility/ASPNET-accessibility-improvement.md
View File

@ -14,8 +14,11 @@ NotPlanned
### Change Description
Starting with the .NET Framework 4.7.1, ASP.NET has improved how ASP.NET Web Controls work with accessibility technology in Visual Studio to better support ASP.NET customers. These include the following changes:
- Changes to implement missing UI accessibility patterns in controls, like the Add Field dialog in the Details View wizard, or the Configure ListView dialog of the ListView wizard.
- Changes to improve the display in High Contrast mode, like the Data Pager Fields Editor.
- Changes to improve the keyboard navigation experiences for controls, like the Fields dialog in the Edit Pager Fields wizard of the DataPager control, the Configure ObjectContext dialog, or the Configure Data Selction dialog of the Configure Data Source wizard.
- [x] Quirked
@ -23,22 +26,27 @@ Starting with the .NET Framework 4.7.1, ASP.NET has improved how ASP.NET Web Con
### Recommended Action
__How to opt in or out of these changes__
**How to opt in or out of these changes**
In order for the Visual Studio Designer to benefit from these changes, it must run on the .NET Framework 4.7.1 or later. The web application can benefit from these changes in either of the following ways:
- Install Visual Studio 2017 15.3 or later, which supports the new accessibility features with the following AppContext Switch by default.
- Opt out of the legacy accessibility behaviors by adding the __Switch.UseLegacyAccessibility__ AppContext Switch to the ```<runtime>``` section in the devenv.exe.config file and setting it to ```false```, as the following example shows.
```
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true|false;key2=true|false -->
<AppContextSwitchOverrides value="...;Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>
- Opt out of the legacy accessibility behaviors by adding the `Switch.UseLegacyAccessibility` AppContext switch to the `<runtime>` section in the devenv.exe.config file and setting it to `false`, as the following example shows.
```xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true|false;key2=true|false -->
<AppContextSwitchOverrides value="...;Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>
```
Applications that target the .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to ```true```.
### Affected APIs

2
Documentation/compatibility/Change-SignedXML-and-SignedCMS-default-algorithms-to-SHA256.md
View File

@ -21,6 +21,7 @@ Starting with the .NET Framework 4.7.1, SHA256 is enabled by default for these o
There are two new context switch values to control whether SHA1 (insecure) or SHA256 is used by default:
- Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
- Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms
For applications that target the .NET Framework 4.7.1 and later versions, if the use of SHA256 is undesirable, you can restore the default to SHA1 by adding the following configuration switch to the [runtime](https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/runtime-element) section of your app config file:
@ -28,6 +29,7 @@ For applications that target the .NET Framework 4.7.1 and later versions, if the
```xml
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />
```
For applications that target the .NET Framework 4.7 and earlier versions, you can opt into this change by adding the following configuration switch to the [runtime](https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/runtime-element) section of your app config file:
```xml

24
Documentation/compatibility/SerialPort-background-thread-exceptions.md
View File

@ -10,9 +10,9 @@ Minor
NotPlanned
### Change Description
Background threads created with `T: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.
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 T: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.
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.
@ -23,19 +23,19 @@ In applications that target the .NET Framework 4.7.1 or a later version, backgro
For apps that target the .NET Framework 4.7.1, you can opt out of the exception handling if it is not desirable by adding the following to to the `<runtime>` section of your `app.config` file:
```xml
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=true" />
</runtime>
```
```xml
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=true" />
</runtime>
```
For apps that target earlier versions of the .NET Framework but run on the .NET Framework 4.7.1 or later, you can opt in to the exception handling by adding the following to to the `<runtime>` section of your `app.config` file:
```xml
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
```
```xml
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
```
### Affected APIs

4
Documentation/compatibility/SignedXml.GetPublicKey-returns-RSACng-on-net462.md
View File

@ -13,12 +13,14 @@ Edge
NotPlanned
### Change Description
Starting with the .NET Framework 4.6.2, the concrete type of the object returned by the `<xref:System.Security.Cryptography.Xml.SignedXml.GetPublicKey%2A?displayProperty=nameWithType>` method changed (without a quirk) from a CryptoServiceProvider implementation to a Cng implementation. This is because the implementation changed from using certificate.PublicKey.Key to using the internal certificate.GetAnyPublicKey which forwards to `<xref:System.Security.Cryprography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey%2A?displayProperty=nameWithType>`.
Starting with the .NET Framework 4.6.2, the concrete type of the object returned by the <xref:System.Security.Cryptography.Xml.SignedXml.GetPublicKey%2A?displayProperty=nameWithType> method changed (without a quirk) from a CryptoServiceProvider implementation to a Cng implementation. This is because the implementation changed from using `certificate.PublicKey.Key` to using the internal `certificate.GetAnyPublicKey` which forwards to <xref:System.Security.Cryprography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey%2A?displayProperty=nameWithType>.
- [x] Quirked
- [ ] Build-time break
### Recommended Action
Starting with apps running on the .NET Framework 4.7.1, you can use the CryptoServiceProvider implementation used by default in the .NET Framework 4.6.1 and earlier versions by adding the following configuration switch to the [runtime](https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/runtime-element) section of your app config file:
```xml

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

@ -20,7 +20,7 @@ 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=fullName> 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.
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:

2
Documentation/compatibility/new-64-bit-jit-compiler.md
View File

@ -18,7 +18,7 @@ The known differences include the following:
- In some cases, execution of production code in a large method body may throw a <xref:System.StackOverflowException>.
- Under certain conditions, structures passed to a method are treated as reference types rather than as value types in Release builds. One of the manifestations of this issue is that the individual items in a collection appear in an unexpected order.
- Under certain conditions, the comparison of <xref:System.UInt16> values with their high bit set is incorrect if optimization is enabled.
- Under certain conditions, particularly when initializing array values, memory initialization by the <xref:System.Reflection.Emit.OpCodes.Initblk?displayProperty=fullName> IL instruction may initialize memory with an incorrect value. This can result either in an unhandled exception or incorrect output.
- Under certain conditions, particularly when initializing array values, memory initialization by the <xref:System.Reflection.Emit.OpCodes.Initblk?displayProperty=nameWithType> IL instruction may initialize memory with an incorrect value. This can result either in an unhandled exception or incorrect output.
- Under certain rare conditions, a conditional bit test can return the incorrect <xref:System.Boolean> value or throw an exception if compiler optimizations are enabled.
- Under certain conditions, if an `if` statement is used to test for a condition before entering a `try` block and in the exit from the `try` block, and the same condition is evaluated in the `catch` or `finally` block, the new 64-bit JIT compiler removes the `if` condition from the `catch` or `finally` block when it optimizes code. As a result, code inside the `if` statement in the `catch` or `finally` block is executed unconditionally.

8
Documentation/compatibility/operationcontext-current-returns-null-in-a-using-clause.md
View File

@ -13,13 +13,13 @@ Investigating
### Change Description
<xref:System.ServiceModel.OperationContext.Current?displayProperty=fullName> may return `null` and a <xref:System.NullReferenceException> may result if all of the following conditions are true:
<xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> may return `null` and a <xref:System.NullReferenceException> may result if all of the following conditions are true:
- You retrieve the value of the <xref:System.ServiceModel.OperationContext.Current?displayProperty=fullName> property in a method that returns a <xref:System.Threading.Tasks.Task> or <xref:System.Threading.Tasks.Task%601>.
- You retrieve the value of the <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> property in a method that returns a <xref:System.Threading.Tasks.Task> or <xref:System.Threading.Tasks.Task%601>.
- You instantiate the <xref:System.ServiceModel.OperationContextScope> object in a `using` clause.
- You retrieve the value of the <xref:System.ServiceModel.OperationContext.Current?displayProperty=fullName> property within the `using statement`. For example:
- You retrieve the value of the <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> property within the `using statement`. For example:
```csharp
using (new OperationContextScope(OperationContext.Current))
@ -47,7 +47,7 @@ To address this issue, you can do the following:
}
```
- Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. This disables the flow of the <xref:System.Threading.ExecutionContext> in <xref:System.ServiceModel.OperationContext.Current?displayProperty=fullName> and restores the behavior of WCF applications in the .NET Framework 4.6.1 and earlier versions. This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
- Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. This disables the flow of the <xref:System.Threading.ExecutionContext> in <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> and restores the behavior of WCF applications in the .NET Framework 4.6.1 and earlier versions. This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
```xml
<appSettings>

6
Documentation/compatibility/product-versioning-changes-in-net-framework-4-6-and-later.md
View File

@ -21,7 +21,7 @@ The following are the detailed changes:
- The <xref:System.Reflection.AssemblyFileVersionAttribute> and <xref:System.Reflection.AssemblyInformationalVersionAttribute> attributes for managed assemblies have Version values in the form 4.6.X.0 for the .NET Framework 4.6 and its point releases, and 4.7.X.0 for the .NET Framework 4.7.
- In the .NET Framework 4.6, 4.6.1, 4.6.2, and 4.7, the <System.Environment.Version?displayProperty=fullName> property returns the fixed version string `4.0.30319.42000`. In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format `4.0.30319.xxxxx` (for example, "4.0.30319.18010"). Note that we do not recommend application code taking any new dependency on the Environment.Version property.
- In the .NET Framework 4.6, 4.6.1, 4.6.2, and 4.7, the <System.Environment.Version?displayProperty=nameWithType> property returns the fixed version string `4.0.30319.42000`. In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format `4.0.30319.xxxxx` (for example, "4.0.30319.18010"). Note that we do not recommend application code taking any new dependency on the Environment.Version property.
- [ ] Quirked // Uses some mechanism to turn the feature on or off, usually using runtime targeting, AppContext or config files. Needs to be turned on automatically for some situations.
- [ ] Build-time break // Causes a break if attempted to recompile
@ -36,9 +36,9 @@ In general, applications should depend on the recommended techniques for detecti
> [!IMPORTANT]
> The subkey name is `NET Framework Setup`, not `.NET Framework Setup`.
- To determine the directory path to the .NET Framework common language runtime, call the <xref:System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory?displayProperty=fullName> method.
- To determine the directory path to the .NET Framework common language runtime, call the <xref:System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory?displayProperty=nameWithType> method.
- To get the CLR version, call the <xref:System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion?displayProperty=fullName> method. For the .NET Framework 4 and its point releases (the .NET Framework 4.5, 4.5.1, 4.5.2, and .NET Framework 4.6, 4.6.1, 4.6.2, and 4.7), it returns the string v4.0.30319.
- To get the CLR version, call the <xref:System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion?displayProperty=nameWithType> method. For the .NET Framework 4 and its point releases (the .NET Framework 4.5, 4.5.1, 4.5.2, and .NET Framework 4.6, 4.6.1, 4.6.2, and 4.7), it returns the string v4.0.30319.
### Affected APIs
* Not detectable via API analysis

6
Documentation/compatibility/servicepointmanager.securityprotocol-defaults-to-securityprotocoltype.systemdefault.md
View File

@ -10,9 +10,9 @@ Minor
NotPlanned
### Change Description
Starting with apps that target the .NET Framework 4.7, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=fullName> property is <xref:System.Net.SecurityProtocolType.SystemDefault?displayProperty=fullName>. This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework. The default varies by operating system and any custom configuration performed by the system administrator. For information on the default SChannel protocol in each version of the Windows operating system, see [Protocols in TLS/SSL (Schannel SSP)](https://msdn.microsoft.com/library/windows/desktop/mt808159.aspx).
Starting with apps that target the .NET Framework 4.7, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property is <xref:System.Net.SecurityProtocolType.SystemDefault?displayProperty=nameWithType>. This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework. The default varies by operating system and any custom configuration performed by the system administrator. For information on the default SChannel protocol in each version of the Windows operating system, see [Protocols in TLS/SSL (Schannel SSP)](https://msdn.microsoft.com/library/windows/desktop/mt808159.aspx).
For applications that target an earlier version of the .NET Framework, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=fullName> property depends on the version of the .NET Framework targeted. See [Retargeting Changes in the .NET Framework 4.6](docs.microsoft.com/dotnet/framework/migration-guide/retargeting) for more information.
For applications that target an earlier version of the .NET Framework, the default value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property depends on the version of the .NET Framework targeted. See [Retargeting Changes in the .NET Framework 4.6](docs.microsoft.com/dotnet/framework/migration-guide/retargeting) for more information.
- [X] Quirked
- [ ] Build-time break
@ -20,7 +20,7 @@ For applications that target an earlier version of the .NET Framework, the defau
### Recommended Action
This change affects applications that target the .NET Framework 4.7 or later versions.
If you prefer to use a defined protocol rather than relying on the system default, you can explicitly set the value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=fullName> property.
If you prefer to use a defined protocol rather than relying on the system default, you can explicitly set the value of the <xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> property.
### Affected APIs
- `P:System.Net.ServicePointManager.SecurityProtocol`

4
Documentation/compatibility/wcf-deadlock-results-when-using-reentrant-services.md
View File

@ -24,13 +24,13 @@ A deadlock may result in a Reentrant service, which restricts instances of the s
To address this issue, you can do the following:
- Set the service's concurrency mode to <xref:System.ServiceModel.ConcurrencyMode.Single?displayProperty=fullName> or <System.ServiceModel.ConcurrencyMode.Multiple?displayProperty=fullName>. For example:
- Set the service's concurrency mode to <xref:System.ServiceModel.ConcurrencyMode.Single?displayProperty=nameWithType> or <System.ServiceModel.ConcurrencyMode.Multiple?displayProperty=nameWithType>. For example:
```csharp
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
```
- Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. This disables the flow of the <xref:System.Threading.ExecutionContext> in <xref:System.ServiceModel.OperationContext.Current?displayProperty=fullName>. This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
- Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. This disables the flow of the <xref:System.Threading.ExecutionContext> in <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType>. This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
```xml
<appSettings>

2
Documentation/compatibility/wcf-services-using-nettcp-with-ssl-security-and-md5-certificate-authentication.md
View File

@ -48,7 +48,7 @@ You can work around this issue so that a WCF client can connect to a WCF server
</configuration>
```
- If the binding is dynamically configured in source code, update the <xref:System.ServiceModel.TcpTransportSecurity.SslProtocols?displayProperty=fullName> property to use TLS 1.1 (<xref:System.Security.Authentication.SslProtocols.Tls11?displayProperty=fullName> or an earlier version of the protocol in the source code.
- If the binding is dynamically configured in source code, update the <xref:System.ServiceModel.TcpTransportSecurity.SslProtocols?displayProperty=nameWithType> property to use TLS 1.1 (<xref:System.Security.Authentication.SslProtocols.Tls11?displayProperty=nameWithType> or an earlier version of the protocol in the source code.
> [!WARNING]
> This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

4
Documentation/compatibility/windows-forms-icon-tobitmap-method-successfully-converts-icons-with-png-frames.md
View File

@ -11,9 +11,9 @@ Investigating
### Change Description
Starting with the apps that target the .NET Framework 4.6, the <xref:System.Drawing.Icon.ToBitmap%2A?displayProperty=fullName> method successfully converts icons with PNG frames into Bitmap objects.
Starting with the apps that target the .NET Framework 4.6, the <xref:System.Drawing.Icon.ToBitmap%2A?displayProperty=nameWithType> method successfully converts icons with PNG frames into Bitmap objects.
In apps that target the .NET Framework 4.5.2 and earlier versions, the <xref:System.Drawing.Icon.ToBitmap%2A?displayProperty=fullName> method throws an <xref:System.ArgumentOutOfRangeException> exception if the Icon object has PNG frames.
In apps that target the .NET Framework 4.5.2 and earlier versions, the <xref:System.Drawing.Icon.ToBitmap%2A?displayProperty=nameWithType> method throws an <xref:System.ArgumentOutOfRangeException> exception if the Icon object has PNG frames.
This change affects apps that are recompiled to target the .NET Framework 4.6 and that implement special handling for the <xref:System.ArgumentOutOfRangeException> that is thrown when an Icon object has PNG frames. When running under the .NET Framework 4.6, the conversion is successful, an <xref:System.ArgumentOutOfRangeException> is no longer thrown, and therefore the exception handler is no longer invoked.

21
Documentation/compatibility/winforms-accessibility-changes-471.md
View File

@ -23,11 +23,14 @@ Windows Forms is improving how it works with accessibility technologies to bette
- [ ] Build-time break
### Recommended Action
__How to opt in or out of these changes__
**How to opt in or out of these changes**
In order for the application to benefit from these changes, it must run on the .NET Framework 4.7.1 or later. The application can benefit from these changes in either of the following ways:
- It is recompiled to target the .NET Framework 4.7.1. These accessibility changes are enabled by default on Windows Forms applications that target the .NET Framework 4.7.1 or later.
- It opts out of the legacy accessibility behaviors by adding the following [AppContext Switch](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element) to the ```<runtime>``` section of the app.config file and setting it to `false`, as the following example shows.
- It opts out of the legacy accessibility behaviors by adding the following [AppContext Switch](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element) to the `<runtime>` section of the app.config file and setting it to `false`, as the following example shows.
```xml
<?xml version="1.0" encoding="utf-8"?>
@ -46,7 +49,7 @@ Applications that target the .NET Framework 4.7.1 or later and want to preserve
For an overview of UI automation, see the [UI Automation Overview](https://docs.microsoft.com/dotnet/framework/ui-automation/ui-automation-overview).
__Added support for UI Automation patterns and properties__
**Added support for UI Automation patterns and properties**
Accessibility clients can take advantage of new WinForms accessibility functionality by using common, publicly described invocation patterns. These patterns are not WinForms-specific. For instance, accessibility clients can call the QueryInterface method on the IAccessible interface (MAAS) to obtain an IServiceProvider interface. If this interface is available, clients can use its QueryService method to request an IAccessibleEx interface. For more information, see [Using IAccessibleEx from a Client](https://msdn.microsoft.com/en-us/library/windows/desktop/dd561924(v=vs.85).aspx). Starting with the .NET Framework 4.7.1, IServiceProvider and [IAccessibleEx]( https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898(v=vs.85).aspx) (where applicable) are available for WinForms accessibility objects.
@ -59,11 +62,11 @@ The .NET Framework 4.7.1 adds support for the fillowing UI automation patterns a
- The `T:System.Windows.Forms.DataGridViewCheckBoxCell` control supports the [Toggle Pattern](https://docs.microsoft.com/dotnet/api/system.windows.automation.togglepattern).
- The `T:System.Windows.Forms.NumericUpDown` and `T:System.Windows.Forms.DomainUpDown` controls support the [Name](https://docs.microsoft.com/dotnet/api/system.windows.automation.automationelement.nameproperty) and have a [ControlType](https://docs.microsoft.com/dotnet/framework/ui-automation/ui-automation-support-for-the-spinner-control-type) of <xref:System.Windows.Automation.ControlType.Spinner?displayProperty=nameWithType>.
__Improvements to PropertyGrid control__
**Improvements to the PropertyGrid control**
The .NET Framework 4.7.1 adds the following improvements to the PropertyBrowser control:
- The __Details__ button in the error dialog that is displayed when the user enters an incorrect value in the `T:System.Windows.Forms.PropertyGrid` control supports the [Expand/Collapse pattern](https://docs.microsoft.com/dotnet/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern), state and name change notifications, and a [ControlType](https://docs.microsoft.com/dotnet/framework/ui-automation/ui-automation-support-for-the-menubar-control-type) property with a value of <xref:System.Windows.Automation.ControlType.MenuItem?displayProperty=nameWithType>.
- The message pane displayed when the __Details__ button of the error dialog is expanded is now keyboard accessible and allows Narrator to announce the content of the error message.
- The **Details** button in the error dialog that is displayed when the user enters an incorrect value in the `T:System.Windows.Forms.PropertyGrid` control supports the [Expand/Collapse pattern](https://docs.microsoft.com/dotnet/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern), state and name change notifications, and a [ControlType](https://docs.microsoft.com/dotnet/framework/ui-automation/ui-automation-support-for-the-menubar-control-type) property with a value of <xref:System.Windows.Automation.ControlType.MenuItem?displayProperty=nameWithType>.
- The message pane displayed when the **Details** button of the error dialog is expanded is now keyboard accessible and allows Narrator to announce the content of the error message.
- The [AccessibleRole](https://docs.microsoft.com/dotnet/api/system.windows.forms.accessiblerole) of rows in `T:System.Windows.Forms.PropertyGrid` control have changed from "Row" to "Cell". The cell maps to UIA ControlType "DataItem", which allows it to support appropriate keyboard shortcuts and Narrator announcements.
- The `T:System.Windows.Forms.PropertyGrid` control rows which represent header items when the `T:System.Windows.Forms.PropertyGrid` control has a `P:System.Windows.Forms.PropertySort` property set to `F:System.Windows.Forms.PropertySory.Categorized` have a [ControlType](https://docs.microsoft.com/dotnet/framework/ui-automation/ui-automation-support-for-the-menubar-control-type) property value of <xref:System.Windows.Automation.ControlType.Button?displayProperty=nameWithType>
- The `T:System.Windows.Forms.PropertyGrid` control rows which represent header items when the `T:System.Windows.Forms.PropertyGrid` control has a `P:System.Windows.Forms.PropertySort` property set to `F:System.Windows.Forms.PropertySory.Categorized` support the [Expand/Collapse pattern](https://docs.microsoft.com/dotnet/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern).
@ -75,7 +78,7 @@ The .NET Framework 4.7.1 adds the following improvements to the PropertyBrowser
- Improved Narrator support for distinguishing the selected alignment in the Alignment Picker.
- When an empty `T:System.Windows.Forms.PropertyGrid` control is displayed on a form, it will now receive focus where previously it would not.
__Use of OS-defined colors in High Contrast themes__
**Use of OS-defined colors in High Contrast themes**
- `T:System.Windows.Forms.Button` and `T:System.Windows.Forms.CheckBox` controls with `P:System.Windows.Forms.Control.FlatStyle` set to <xref:System.Windows.Forms.FlatStyle.System?displayProperty=nameWithType>, which is the default style, now use OS-defined colors in High Contrast theme when selected. Previously, text and background colors were not contrasting and were hard to read.
- `T:System.Windows.Forms.Button`, `T:System.Windows.Forms.CheckBox`, `T:System.Windows.Forms.RadioButton`, `T:System.Windows.Forms.Label`, `T:System.Windows.Forms.LinkLabel` and `T:System.Windows.Forms.GroupBox` with`P:System.Windows.Forms.Control.Enabled` set to _false_, used a shaded color to render text in High Contrast themes, resulting in low contrast against the background. Now these controls use "Disabled Text" color defined by the OS. This fix applies to controls with `P:System.Windows.Forms.Control.FlatStyle` property set to a value other than `F:System.Windows.Forms.FlatStyle.System`. The latter controls are rendered by the OS.
@ -89,11 +92,11 @@ NOTE: Windows10 has changed values for some high contrast system colors. Windows
   <!-- Windows 10 -->
   <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
```
__Improved keyboard navigation__
**Improved keyboard navigation**
- When a `T:System.Windows.Forms.ComboBox` control has `P:System.Windows.Forms.ComboBox.DropDownStyle` set to `F:System.Windows.Forms.DropDownStyle.DropDownList` and is the first control in the tab order on the form, it now displays a focus rectangle when the parent form is opened using the keyboard. Before this change, keyboard focus was on this control, but a focus indicator was not rendered.
__Improved Narrator support__
**Improved Narrator support**
- The `T:System.Windows.Forms.MonthCalendar` control has added support for assistive technologies to access the control, including the ability for Narrator to read the value of the control when previously it could not.
- The `T:System.Windows.Forms.CheckedListBox` control now notifies Narrator when the `P:System.Windows.Forms.CheckState` property has been changed. Previously, Narrator did not recieve notification and as a result users would not be informed that the `P:System.Windows.Forms.CheckState` had been updated.
- The `T:System.Windows.Forms.LinkLabel` control has changed the way it notifies Narrator of the text of in the control. Previously, Narrator announced this text twice and read "&" symbols as real text even though they are not visible to a user. The duplicated text was removed from the Narrator announcements, as well as unnecessary "&" symbols.