Runtime Changes for Migration from .NET Framework 4.6.1 to 4.7

If you are migrating from the .NET Framework 4.6.1 to 4.7, review the following topics for application compatibility issues that may affect your app:

Data

Attempting a TCP/IP connection to a SQL Server database that resolves to localhost fails

Details

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)"

Suggestion

This issue has been addressed and the previous behavior restored in the .NET Framework 4.6.2. To connect to a SQL Server database that resolves to localhost, upgrade to the .NET Framework 4.6.2.

Name Value
Scope Minor
Version 4.6
Type Runtime

Connection pool blocking period for Azure SQL databases is removed

Details

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.

Suggestion

If this behavior is undesirable, the connection pool blocking period can be configured by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property introduced in the .NET Framework 4.6.2. The value of the property is a member of the System.Data.SqlClient.PoolBlockingPeriod enumeration that can take either of three values:

The previous behavior can be restored by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property to AlwaysBlock.

Name Value
Scope Minor
Version 4.6.2
Type Runtime

Affected APIs

-DbConnection.OpenAsync()

  • SqlConnection.Open()
  • SqlConnection.OpenAsync(CancellationToken)
  • |

    Globalization

    Unicode standard version 8.0 categories now supported

    Details

    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.

    Suggestion

    Review code and remove/change logic that depends on hard-coded Unicode character categories.

    Name Value
    Scope Minor
    Version 4.6.2
    Type Runtime

    Affected APIs

    -Char.GetUnicodeCategory(Char)

  • CharUnicodeInfo.GetUnicodeCategory(Char)
  • CharUnicodeInfo.GetUnicodeCategory(String, Int32)
  • |

    JIT

    Incorrect code generation when passing and comparing UInt16 values

    Details

    Because of changes introduced in the .NET Framework 4.7, in some cases the code generated by the JIT compiler in applications running on the .NET Framework 4.7 incorrectly compares two T:System.UInt16 values. For more information, see Issue #11508: Silent bad codegen when passing and comparing ushort args on GitHub.com.

    Suggestion

    If you encounter issues in the comparison of 16-bit unsigned values in the .NET Framework 4.7, upgrade to the .NET Framework 4.7.1.

    Name Value
    Scope Edge
    Version 4.7
    Type Runtime

    Security

    RSACng and DSACng are once again usable in Partial Trust scenarios

    Details

    CngLightup (used in several higher-level crypto apis, such as System.Security.Cryptography.Xml.EncryptedXml) and System.Security.Cryptography.RSACng in some cases rely on full trust. These include P/Invokes without asserting SecurityPermissionFlag.UnmanagedCode permissions, and code paths where System.Security.Cryptography.CngKey has permission demands for SecurityPermissionFlag.UnmanagedCode. Starting with the .NET Framework 4.6.2, CngLightup was used to switch to System.Security.Cryptography.RSACng wherever possible. As a result, partial trust apps that successfully used System.Security.Cryptography.Xml.EncryptedXml began to fail and throw SecurityException exceptions.This change adds the required asserts so that all functions using CngLightup have the required permissions.

    Suggestion

    If this change in the .NET Framework 4.6.2 has negatively impacted your partial trust apps, upgrade to the .NET Framework 4.7.1.

    Name Value
    Scope Edge
    Version 4.6.2
    Type Runtime

    Affected APIs

    -DSACng(CngKey)

  • DSACng.Key
  • DSACng.LegalKeySizes
  • DSACng.CreateSignature(Byte[])
  • DSACng.VerifySignature(Byte[], Byte[])
  • RSACng(CngKey)
  • RSACng.Key
  • RSACng.Decrypt(Byte[], RSAEncryptionPadding)
  • RSACng.SignHash(Byte[], HashAlgorithmName, RSASignaturePadding)
  • |

    RSACng.VerifyHash now returns False for any verification failure

    Details

    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 System.Security.Cryptography.CryptographicException if the signature itself is badly formatted.

    Suggestion

    Any code whose execution depends on handling the System.Security.Cryptography.CryptographicException should instead execute if validation fails and the method returns False.

    Name Value
    Scope Minor
    Version 4.6.2
    Type Runtime

    Affected APIs

    -RSACng.VerifyHash(Byte[], Byte[], HashAlgorithmName, RSASignaturePadding)|

    SignedXml and EncryptedXml Breaking Changes

    Details

    In .NET Framework 4.6.2, Security fixes in System.Security.Cryptography.Xml.SignedXml and System.Security.Cryptography.Xml.EncryptedXml lead to different run-time behaviors. For example,

    • If a document has multiple elements with the same id attribute and a signature targets one of those elements as the root of the signature, the document will now be considered invalid.
    • Documents using non-canonical XPath transform algorithms in references are now considered invalid.
    • Documents using non-canonical XSLT transform algorithms in references are now consider invalid.
    • Any program making use of external resource detached signatures will be unable to do so.

    Suggestion

    Developers might want to review the usage of XmlDsigXsltTransform and XmlDsigXsltTransform, as well as types derived from Transform since a document receiver may not be able to process it.

    Name Value
    Scope Minor
    Version 4.6.2
    Type Runtime

    Affected APIs

    -System.Security.Cryptography.Xml.Transform

  • System.Security.Cryptography.Xml.XmlDsigXPathTransform
  • System.Security.Cryptography.Xml.XmlDsigXsltTransform
  • |

    Windows Communication Foundation (WCF)

    Remove Ssl3 from the WCF TransportDefaults

    Details

    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.

    Suggestion

    If Ssl3 is required, use one of the following configuration mechanisms to add Ssl3 to the list of negotiated protocols.

    • SslProtocols
    • SslProtocols
    • <
    • [<sslStreamSecurity> section of <customBinding>]~/docs/framework/configure-apps/file-schema/wcf/sslstreamsecurity.md)

    Name Value
    Scope Edge
    Version 4.6.2
    Type Runtime

    Affected APIs

    -SslStreamSecurityBindingElement.SslProtocols

  • TcpTransportSecurity.SslProtocols
  • |

    Windows Presentation Foundation (WPF)

    Changing the IsEnabled property of the parent of a TextBlock control affects any child controls

    Details

    Starting with the .NET Framework 4.6.2, changing the System.Windows.UIElement.IsEnabled property of the parent of a System.Windows.Controls.TextBlock control affects any child controls (such as hyperlinks and buttons) of the System.Windows.Controls.TextBlock control.In the .NET Framework 4.6.1 and earlier versions, controls inside a System.Windows.Controls.TextBlock did not always reflect the state of the System.Windows.UIElement.IsEnabled property of the System.Windows.Controls.TextBlock parent.

    Suggestion

    None. This change conforms to the expected behavior for controls inside a System.Windows.Controls.TextBlock control.

    Name Value
    Scope Minor
    Version 4.6.2
    Type Runtime

    Affected APIs

    -UIElement.IsEnabled|

    CoerceIsSelectionBoxHighlighted

    Details

    Certain sequences of actions involving a System.Windows.Controls.ComboBox and its data source can result in a System.NullReferenceException.

    Suggestion

    If possible, upgrade to .NET Framework 4.6.2.

    Name Value
    Scope Minor
    Version 4.6
    Type Runtime

    Affected APIs

    -ComboBox.IsSelectionBoxHighlighted|

    Crash in Selector when removing an item from a custom INCC collection

    Details

    An T:System.InvalidOperationException can occur in the following scenario:

    • The ItemsSource for a T:System.Windows.Controls.Primitives.Selector is a collection with a custom implementation of T:System.Collections.Specialized.INotifyCollectionChanged.
    • The selected item is removed from the collection.
    • The T:System.Collections.Specialized.NotifyCollectionChangedEventArgs has P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex = -1 (indicating an unknown position).
    The exception's callstack begins at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element)This exception can occur in .NET Framework 4.5 if the application has more than one Dispatcher thread. In .NET Framework 4.7 the exception can also occur in applications with a single Dispatcher thread. The issue is fixed in .NET Framework 4.7.1.

    Suggestion

    Upgrade to .NET Framework 4.7.1.

    Name Value
    Scope Minor
    Version 4.7
    Type Runtime

    Horizontal scrolling and virtualization

    Details

    This change applies to an System.Windows.Controls.ItemsControl that does its own virtualization in the direction orthogonal to the main scrolling direction (the chief example is System.Windows.Controls.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 System.Windows.Controls.Primitives.IScrollInfo.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 System.Windows.Controls.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 System.Windows.Controls.Primitives.IScrollInfo.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 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset after a horizontal scroll, whether invoked by the end user or by an explicit call to SetHorizontalOffset(Double).

    Suggestion

    An app that uses a predicted value for System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset should be changed to fetch the actual value (and the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) after any horizontal scroll that could change System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth due to de-virtualization.

    Name Value
    Scope Minor
    Version 4.6.2
    Type Runtime

    Affected APIs

    -System.Windows.Controls.Primitives.IScrollInfo|

    Items.Clear does not remove duplicates from SelectedItems

    Details

    Suppose a Selector (with multiple selection enabled) has duplicates in its System.Windows.Controls.Primitives.MultiSelector.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 System.Windows.Controls.Primitives.MultiSelector.SelectedItems; only the first instance is removed. Furthermore, subsequent use of System.Windows.Controls.Primitives.MultiSelector.SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as System.ArgumentException, because System.Windows.Controls.Primitives.MultiSelector.SelectedItems contains items that are no longer in the data source.

    Suggestion

    Upgrade if possible to .NET Framework 4.6.2.

    Name Value
    Scope Minor
    Version 4.5
    Type Runtime

    Affected APIs

    -MultiSelector.SelectedItems|

    Item-scrolling a flat list with items of different pixel-height

    Details

    When an System.Windows.Controls.ItemsControl displays a collection using virtualization (IsVirtualizing=true) and item- scrolling (ScrollUnit=Item), and when the control scrolls to display an item whose height in pixels differs from its neighbors, the System.Windows.Controls.VirtualizingStackPanel iterates over all items in the collection. The UI is unresponsive during this iteration; if the collection is large, this can be perceived as a hang. The iteration occurs in other circumstances, even in previous .NET Framework releases. For example, it occurs when pixel-scrolling (ScrollUnit=Pixel) upon encountering an item with different pixel height, and when item-scrolling hierarchical data (such as a System.Windows.Controls.TreeView or an System.Windows.Controls.ItemsControl with grouping enabled) upon encountering an item with a different number of descendant items than its neighbors.For the case of item-scrolling and different pixel height, the iteration was introduced in .NET Framework 4.6.1 to fix bugs in the layout of hierarchical data. It is not needed if the data is flat (no hierarchy), and .NET Framework 4.6.2 does not do it in that case.

    Suggestion

    If the iteration occurs in .NET Framework 4.6.1 but not in earlier releases - that is, if the System.Windows.Controls.ItemsControl is item- scrolling a flat list with items of different pixel height - there are two remedies:

    1. Install .NET Framework 4.6.2.
    2. Install hotfix HR 1605 for .NET Framework 4.6.1.

    Name Value
    Scope Minor
    Version 4.6.1
    Type Runtime

    Affected APIs

    -System.Windows.Controls.VirtualizingStackPanel|

    ObjectDisposedException thrown by WPF spellchecker

    Details

    WPF applications occasionally crash during application shutdown with an System.ObjectDisposedException thrown by the spellchecker. This is fixed in .NET Framework 4.7 WPF by handling the exception gracefully, and thus ensuring that applications are no longer adversely affected. It should be noted that occasional first-chance exceptions would continue to be observed in applications running under a debugger.

    Suggestion

    Upgrade to .NET Framework 4.7

    Name Value
    Scope Edge
    Version 4.6.1
    Type Runtime

    Resizing a Grid can hang

    Details

    An infinite loop can occur during layout of a T:System.Windows.Controls.Grid under the following circumstances:

    • Row definitions contain two *-rows, both declaring a MinHeight and a MaxHeight.
    • Content of the *-rows doesn't exceed the corresponding MaxHeight
    • The Grid's available height is exceeded by the first MinHeight (plus any other fixed or Auto rows)
    • The app targets .NET Framework 4.7, or opts in to the 4.7 allocation algorithm by setting Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false
    The loop would also happen with more than two rows, or in the analogous case for columns. The issue is fixed in .NET Framework 4.7.1.

    Suggestion

    Upgrade to .NET Framework 4.7.1. Alternatively, if you don't need the 4.7 allocation algorithm you can use the following configuration setting:

    <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
    </runtime>
    

    Name Value
    Scope Edge
    Version 4.7
    Type Runtime

    WPF Printing Stack Update

    Details

    WPF's Printing APIs using System.Printing.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.

    Suggestion

    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.

    Name Value
    Scope Edge
    Version 4.7
    Type Runtime

    WPF Spell Checking fails in unexpected ways

    Details

    This includes a number of WPF Spell Checker issues:

    Suggestion

    Issue #1 - This has been fixed in .NET Framework 4.6.2 Issue #2 - WPF Spell Checker is no longer supported when applications are launched using 'run as different user'. Starting .NET Framework 4.6.2, applications launched in this manner will no longer crash unexpectedly - instead the Spell Checker will be silently disabled. Issue #3 - This has been fixed in .NET Framework 4.6.2.

    Name Value
    Scope Edge
    Version 4.6.1
    Type Runtime

    Windows Workflow Foundation (WF)

    Workflow now throws original exception instead of NullReferenceException in some cases

    Details

    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 System.NullReferenceException, masking the original exception.In the .NET Framework 4.7, the previously masked exception is thrown.

    Suggestion

    If your code relies on handling the System.NullReferenceException, change it to catch the exceptions that could be thrown from your custom activities.

    Name Value
    Scope Minor
    Version 4.7
    Type Runtime

    Affected APIs

    -CodeActivity.Execute(CodeActivityContext)

  • AsyncCodeActivity.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
  • AsyncCodeActivity<TResult>.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
  • WorkflowInvoker.Invoke()
  • |

    Workflow SQL persistence adds primary key clusters and disallows null values in some columns

    Details

    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.

    Suggestion

    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.

    Name Value
    Scope Edge
    Version 4.7
    Type Runtime