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:
This is a significant change that affects a large number of apps or that requires substantial modification of code.
This is a change that affects a small number of apps or that requires minor modification of code.
This is a change that affects apps under very specific scenarios that are not common.
This is a change that has no noticeable effect on the app's developer or user. The app should not require modification because of this change.
If you are migrating from the .NET Framework 4.6 to 4.7.1, review the following topics for application compatibility issues that may affect your app:
Attempting a TCP/IP connection to a SQL Server database that resolves to localhost fails
In the .NET Framework 4.6 and 4.6.1, attempting a TCP/IP connection to a SQL Server database that resolves to localhost fails with the error, "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"
This issue has been addressed and the previous behavior restored in the .NET Framework 4.6.2. To connect to a SQL Server databsae that resolves to localhost, upgrade to the .NET Framework 4.6.2.
Connection pool blocking period for Azure SQL databases is removed
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 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.
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 attempt cannot be retried quickly, because the connection pool caches the error and re-throws it for 5 seconds to 1 minute. For more information, see SQL Server Connection Pooling (ADO.NET). This behavior is problematic for connections to Azure SQL databases, which often fail with transient errors that are typically recovered from within a few seconds. The connection pool blocking feature means that the app cannot connect to the database for an extensive period, even though the database is available and the app needs to render within a few seconds.
If this behavior is undesirable, the connection pool blocking period can be configured by setting the PoolBlockingPeriod property introduced in the .NET Framework 4.6.2. The value of the property is a member of the PoolBlockingPeriod enumeration that can take either of three values:
Unicode standard version 8.0 categories now supported
In .NET Framework 4.6.2, Unicode data has been upgraded from Unicode Standard version 6.3 to version 8.0. When requesting Unicode character categories in .NET Framework 4.6.2, some results might not match the results in previous .NET Framework versions. This change mostly affects Cherokee syllables and New Tai Lue vowels signs and tone marks.
Review code and remove/change logic that depends on hard-coded Unicode character categories.
RSACng.VerifyHash now returns False for any verification failure
Starting with the .NET Framework 4.6.2, this method returns False if the signature itself is badly formatted. It now returns false for any verification failure.In the .NET Framework 4.6 and 4.6.1, the method throws a CryptographicException if the signature itself is badly formatted.
Any code whose execution depends on handling the CryptographicException should instead execute if validation fails and the method returns False.
Contract.Invariant or Contract.Requires<TException> do not consider String.IsNullOrEmpty to be pure
For apps that target the .NET Framework 4.6.1, if the invariant contract for Contract.Invariant or the precondition contract for Requires calls the String.IsNullOrEmpty method, the rewriter emits compiler warning CC1036: "Detected call to method 'System.String.IsNullOrWhteSpace(System.String)' without [Pure] in method." This is a compiler warning rather than a compiler error.
This behavior was addressed in GitHub Issue #339. To eliminate this warning, you can download and compile an updated version of the source code for the Code Contracts tool from GitHub. Download information is found at the bottom of the page.
When using NetTcp with transport security and a credential type of certificate, the SSL 3 protocol is no longer a default protocol used for negotiating a secure connection. In most cases there should be no impact to existing apps as TLS 1.0 has always been included in the protocol list for NetTcp. All existing clients should be able to negotiate a connection using at least TLS1.0.
If Ssl3 is required, use one of the following configuration mechanisms to add Ssl3 to the list of negotiated protocols.
If you encounter compatibility issues with this change on the .NET Framework 4.7.1 or a later version, you can opt-out of it by adding the following line to the <runtime> section of the app.config file::
WCF MsmqSecureHashAlgorithm default value is now SHA256
Starting with the .NET Framework 4.7.1, the default message signing algorithm in WCF for Msmq messages is SHA256. In the .NET Framework 4.7 and earlier versions, the default message signing algorithm is SHA1.
If you run into compatibility issues with this change on the .NET Framework 4.7.1 or later, you can opt-out the change by adding the following line to the <runtime>section of your app.config file:
WCF PipeConnection.GetHashAlgorithm now uses SHA256
Starting with the .NET Framework 4.7.1, Windows Communication Foundation uses a SHA256 hash to generate random names for named pipes. In the .NET Framework 4.7 and earlier versions, it used a SHA1 hash.
If you run into compatibility issue with this change on the .NET Framework 4.7.1 or later, you can opt-out it by adding the following line to the <runtime> section of your app.config file:
Changing the IsEnabled property of the parent of a TextBlock control affects any child controls
Starting with the .NET Framework 4.6.2, changing the IsEnabled property of the parent of a TextBlock control affects any child controls (such as hyperlinks and buttons) of the TextBlock control.In the .NET Framework 4.6.1 and earlier versions, controls inside a TextBlock did not always reflect the state of the IsEnabled property of the TextBlock parent.
None. This change conforms to the expected behavior for controls inside a TextBlock control.
This change applies to an ItemsControl that does its own virtualization in the direction orthogonal to the main scrolling direction (the chief example is DataGrid with EnableColumnVirtualization="True"). The outcome of certain horizontal scrolling operations has been changed to produce results that are more intuitive and more analogous to the results of comparable vertical operations.
The operations include "Scroll Here" and "Right Edge", to use the names from the menu obtained by right-clicking a horizontal scrollbar. Both of these compute a candidate offset and call SetHorizontalOffset(Double).
After scrolling to the new offset, the notion of "here" or "right edge" may have changed because newly de-virtualized content has changed the value of ExtentWidth.
Prior to .NET Framework 4.6.2, the scroll operation simply uses the candidate offset, even though it may not be "here" or at the "right edge" any more. This results in effects like "bouncing" the scroll thumb, best illustrated by example. Suppose a DataGrid has ExtentWidth=1000 and Width=200. A scroll to "Right Edge" uses candidate offset 1000 - 200 = 800. While scrolling to that offset, new columns are de- virtualized; let's suppose they are very wide, so that the ExtentWidth changes to 2000. The scroll ends with HorizontalOffset=800, and the thumb "bounces" back to near the middle of the scrollbar - precisely at 800/2000 = 40%.
The change is to recompute a new candidate offset when this situation occurs, and try again. (This is how vertical scrolling works already.)
The change produces a more predictable and intuitive experience for the end user, but it could also affect any app that depends on the exact value of HorizontalOffset after a horizontal scroll, whether invoked by the end user or by an explicit call to SetHorizontalOffset(Double).
An app that uses a predicted value for HorizontalOffset should be changed to fetch the actual value (and the value of ExtentWidth) after any horizontal scroll that could change ExtentWidth due to de-virtualization.
Items.Clear does not remove duplicates from SelectedItems
Suppose a Selector (with multiple selection enabled) has duplicates in its SelectedItems collection - the same item appears more than once. Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from SelectedItems; only the first instance is removed. Furthermore, subsequent use of SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as ArgumentException, because SelectedItems contains items that are no longer in the data source.
WPF's Printing APIs using PrintQueue now call Window's Print Document Package API in favor of the now deprecated XPS Print API. The change was made with serviceability in mind; neither users nor developers should see any changes in behavior or API usage. The new printing stack is enabled by default when running in Windows 10 Creators Update. The old printing stack will still continue to work just as before in older Windows versions.
To use the old stack in Windows 10 Creators Update, set the UseXpsOMPrinting REG_DWORD value of the HKEY_CURRENT_USER\Software\Microsoft.NETFramework\Windows Presentation Foundation\Printing registry key to 1.
Windows Workflow Foundation (WF)
Workflow now throws original exception instead of NullReferenceException in some cases
In the .NET Framework 4.6.2 and earlier versions, when the Execute method of a workflow activity throws an exception with a null value for the Message property, the System.Activities Workflow runtime throws a NullReferenceException, masking the original exception.In the .NET Framework 4.7, the previously masked exception is thrown.
If your code relies on handling the NullReferenceException, change it to catch the exceptions that could be thrown from your custom activities.
Workflow SQL persistence adds primary key clusters and disallows null values in some columns
Starting with the .NET Framework 4.7, the tables created for the SQL Workflow Instance Store (SWIS) by the SqlWorkflowInstanceStoreSchema.sql script use clustered primary keys. Because of this, identities do not support null values. The operation of SWIS is not impacted by this change. The updates were made to support SQL Server Transactional Replication.
The SQL file SqlWorkflowInstanceStoreSchemaUpgrade.sql must be applied to existing installations in order to experience this change. New database installations will automatically have the change.