Runtime Changes for Migration from .NET Framework 4.6 to 4.8
- (4.0 | 4.5)
- (4.0 | 4.5.1)
- (4.0 | 4.5.2)
- (4.0 | 4.6)
- (4.0 | 4.6.1)
- (4.0 | 4.6.2)
- (4.0 | 4.7)
- (4.0 | 4.7.1)
- (4.0 | 4.7.2)
- (4.0 | 4.8)
- (4.5 | 4.5.1)
- (4.5 | 4.5.2)
- (4.5 | 4.6)
- (4.5 | 4.6.1)
- (4.5 | 4.6.2)
- (4.5 | 4.7)
- (4.5 | 4.7.1)
- (4.5 | 4.7.2)
- (4.5 | 4.8)
- (4.5.1 | 4.5.2)
- (4.5.1 | 4.6)
- (4.5.1 | 4.6.1)
- (4.5.1 | 4.6.2)
- (4.5.1 | 4.7)
- (4.5.1 | 4.7.1)
- (4.5.1 | 4.7.2)
- (4.5.1 | 4.8)
- (4.5.2 | 4.6)
- (4.5.2 | 4.6.1)
- (4.5.2 | 4.6.2)
- (4.5.2 | 4.7)
- (4.5.2 | 4.7.1)
- (4.5.2 | 4.7.2)
- (4.5.2 | 4.8)
- (4.6 | 4.6.1)
- (4.6 | 4.6.2)
- (4.6 | 4.7)
- (4.6 | 4.7.1)
- (4.6 | 4.7.2)
- (4.6 | 4.8)
- (4.6.1 | 4.6.2)
- (4.6.1 | 4.7)
- (4.6.1 | 4.7.1)
- (4.6.1 | 4.7.2)
- (4.6.1 | 4.8)
- (4.6.2 | 4.7)
- (4.6.2 | 4.7.1)
- (4.6.2 | 4.7.2)
- (4.6.2 | 4.8)
- (4.7 | 4.7.1)
- (4.7 | 4.7.2)
- (4.7 | 4.8)
- (4.7.1 | 4.7.2)
- (4.7.1 | 4.8)
- (4.7.2 | 4.8)
- (4.8 | 4.8.1)
If you are migrating from the .NET Framework 4.6 to 4.8, review the following topics for application compatibility issues that may affect your app:
ASP.NET
ASP.NET Fix handling of InputAttributes and LabelAttributes for WebForms CheckBox control
Details
For applications that target .NET Framework 4.7.2 and earlier versions, CheckBox.InputAttributes and CheckBox.LabelAttributes that are programmatically added to a WebForms CheckBox control are lost after postback. For applications that target .NET Framework 4.8 or later versions, they are preserved after postback.
Suggestion
For the correct behavior for restoring attributes on postback, set the targetFrameworkVersion
to 4.8 or higher. For example:
<configuration>
<system.web>
<httpRuntime targetFramework="4.8"/>
</system.web>
</configuration>
Setting it lower, or not at all, preserves the old incorrect behavior.
Name | Value |
---|---|
Scope | Unknown |
Version | 4.8 |
Type | Runtime |
Affected APIs
ASP.NET Incorrect multipart handling may result in lost form data.
Details
In applications that target .NET Framework 4.7.2 and earlier versions, ASP.NET might incorrectly parse multipart boundary values, resulting in form data being unavailable during request execution. Applications that target .NET Framework 4.8 or later versions correctly parse multipart data, so form values are available during request execution.
Suggestion
Starting with applications running on .NET Framework 4.8, when targeting .NET Framework 4.8 or later by using the targetFrameworkVersion
element, the default behavior changes to strip delimiters. When targeting previous framework versions or not using targetFrameworkVersion
, trailing delimiters for some values are still returned.
This behavior can also be explicitly controlled with an appSetting
:
<configuration>
<appSettings>
...
<add key="aspnet:UseLegacyMultiValueHeaderHandling" value="true"/>
...
</appSettings>
</configuration>
Name | Value |
---|---|
Scope | Unknown |
Version | 4.8 |
Type | Runtime |
Affected APIs
ASP.NET ValidationContext.MemberName is not NULL when using custom DataAnnotations.ValidationAttribute
Details
In .NET Framework 4.7.2 and earlier versions, when using a custom System.ComponentModel.DataAnnotations.ValidationAttribute, the ValidationContext.MemberName property returns null
. In .NET Framework 4.8 version prior to the October 2019 update, it returns the member name. Starting with .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8, it returns null
by default, but you can opt in to return the member name instead.
Suggestion
Add the following setting to your web.config file for the property to return the member name in .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8 and later versions:
<configuration>
<appSettings>
...
<add key="aspnet:GetValidationMemberName" value="true"/>
...
</appSettings>
</configuration>
In .NET Framework 4.8 version prior to the October 2019 update, adding this to your web.config file restores the previous behavior and the property returns null
.
Name | Value |
---|---|
Scope | Unknown |
Version | 4.8 |
Type | Runtime |
Affected APIs
Core
.NET COM successfully marshals ByRef SafeArray parameters on events
Details
In .NET Framework 4.7.2 and earlier versions, a ByRef SafeArray parameter on a COM event would fail to marshal back to native code. With this change, the SafeArray is now marshalled successfully.
- [ x ] Quirked
Suggestion
If properly marshalling ByRef SafeArray parameters on COM Events breaks execution, you can disable this code by adding the following configuration switch to your application config:
<appSettings>
<add key="Switch.System.Runtime.InteropServices.DoNotMarshalOutByrefSafeArrayOnInvoke" value="true" />
</appSettings>
Name | Value |
---|---|
Scope | Minor |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
.NET Interop will now QueryInterface for IAgileObject (a WinRT interface)
Details
When using a WinRT event with a .NET delegate, Windows will QI for IAgileObject starting with .NET Framework 4.8. In previous versions of .NET Framework, the runtime would fail that QI, and the event could not be subscribed.
- [ x ] Quirked
Suggestion
If enabling the QI for IAgileObject breaks execution, you can disable this code by setting the following configuration.
Method 1: Environment variable
Set the following environment variable: COMPLUS_DisableCCWSupportIAgileObject=1
This method affects any environment that inherits this environment variable. This might be just a single console session, or it might affect the entire machine if you set the environment variable globally. The environment variable name is not case-sensitive.
Method 2: Registry
Using Registry Editor (regedit.exe), find either of the following subkeys:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework
- HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFramework
Then add the following entry:
Name: DisableCCWSupportIAgileObject Type: DWORD (32-bit) value (also called REG_DWORD) Data: 1
You can use the Windows REG.EXE tool to add this value from a command line or scripting environment. For example:
reg add HKLM\SOFTWARE\Microsoft.NETFramework /v DisableCCWSupportIAgileObject /t REG_DWORD /d 1
In this case, HKLM
is used instead of HKEY_LOCAL_MACHINE
. Use reg add /?
to see help on this syntax. The registry value name is not case-sensitive.
Name | Value |
---|---|
Scope | Edge |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
Allow Unicode in URIs that resemble UNC shares
Details
In System.Uri, constructing a file URI containing both a UNC share name and Unicode characters will no longer result in a URI with invalid internal state. The behavior will change only when all of the following are true:
- The URI has the scheme
file:
and is followed by four or more slashes. - The host name begins with an underscore or other non-reserved symbol.
- The URI contains Unicode characters.
Suggestion
Applications working with URIs consistently containing Unicode could have conceivably used this behavior to disallow references to UNC shares. Those applications should use IsUnc instead.
Name | Value |
---|---|
Scope | Edge |
Version | 4.7.2 |
Type | Runtime |
Affected APIs
Support special relative URI notation when Unicode is present
Details
Uri will no longer throw a NullReferenceException when calling TryCreate on certain relative URIs containing Unicode. The simplest reproduction of the NullReferenceException is below, with the two statements being equivalent:
bool success = Uri.TryCreate("http:%C3%A8", UriKind.RelativeOrAbsolute, out Uri href);
bool success = Uri.TryCreate("http:รจ", UriKind.RelativeOrAbsolute, out Uri href);
To reproduce the NullReferenceException, the following items must be true:
- The URI must be specified as relative by prepending it with 'http:' and not following it with '//'.
- The URI must contain percent-encoded Unicode or unreserved symbols.
Suggestion
Users depending on this behavior to disallow relative URIs should instead specify UriKind.Absolute when creating a URI.
Name | Value |
---|---|
Scope | Edge |
Version | 4.7.2 |
Type | Runtime |
Affected APIs
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 |
Affected APIs
Not detectable via API analysis.
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
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)
Runtime
Improved WCF chain trust certificate validation for Net.Tcp certificate authentication
Details
.NET Framework 4.7.2 improves chain trust certificate validation when using certificate authentication with transport security with WCF. With this improvement, client certificates that are used to authenticate to a server must be configured for client authentication. Similarly server certificates that are for the authenticating a server must be configured for server authentication. With this change, if the root certificate is disabled, the certificate chain validation fails. The same change was also made to .NET Framework 3.5 and later versions via Windows security roll-up. You can find more information here.This change is on by default and can be turned off by a configuration setting.
Suggestion
Validate if your server and client certification has the required EKU OID. If not, update your certification.
Validate if your root certificate is invalid. If so, update the root certificate.
If you can't update the certificate, you can work around the breaking change temporarily with the following configuration setting. However, opting out of the change will leave your system vulnerable to the security issue.
<appSettings> <add key="wcf:useLegacyCertificateUsagePolicy" value="true" /> </appSettings>
Name | Value |
---|---|
Scope | Minor |
Version | 4.7.2 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
Security
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
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
Tools
Contract.Invariant or Contract.Requires<TException> do not consider String.IsNullOrEmpty to be pure
Details
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.IsNullOrWhiteSpace(System.String)' without [Pure] in method." This is a compiler warning rather than a compiler error.
Suggestion
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.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.1 |
Type | Runtime |
Affected APIs
Web Applications
"dataAnnotations:dataTypeAttribute:disableRegEx" app setting is on by default in .NET Framework 4.7.2
Details
In .NET Framework 4.6.1, an app setting ("dataAnnotations:dataTypeAttribute:disableRegEx"
) was introduced that allows users to disable the use of regular expressions in data type attributes (such as System.ComponentModel.DataAnnotations.EmailAddressAttribute, System.ComponentModel.DataAnnotations.UrlAttribute, and System.ComponentModel.DataAnnotations.PhoneAttribute). This helps to reduce security vulnerability such as avoiding the possibility of a Denial of Service attack using specific regular expressions.
In .NET Framework 4.6.1, this app setting to disable RegEx usage was set to false
by default. Starting with .NET Framework 4.7.2, this config switch is set to true
by default to further reduce secure vulnerability for web applications that target .NET Framework 4.7.2 and above.
Suggestion
If you find that regular expressions in your web application do not work after upgrading to .NET Framework 4.7.2, you can update the value of the "dataAnnotations:dataTypeAttribute:disableRegEx"
setting to false
to revert to the previous behavior.
<configuration>
<appSettings>
...
<add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
...
</appSettings>
</configuration>
Name | Value |
---|---|
Scope | Minor |
Version | 4.7.2 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6.2 |
Type | Runtime |
Affected APIs
svcTraceViewer ComboBox high contrast change
Details
In the Microsoft Service Trace Viewer tool, ComboBox controls were not displayed in the correct color in certain high contrast themes. The issue was fixed in .NET Framework 4.7.2. However, due to .NET Framework SDK backward compatibility requirements, the fix was not visible to customers by default. .NET 4.8 surfaces this change by adding the following AppContext configuration switches to the svcTraceViewer.exe.config file:
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
Suggestion
If you don't want to have the high contrast behavior change, you can disable it by removing the following section from the svcTraceViewer.exe.config file:
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
Name | Value |
---|---|
Scope | Edge |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
WCF AddressHeaderCollection now throws an ArgumentException if an addressHeader element is null
Details
Starting with the .NET Framework 4.7.1, the AddressHeaderCollection(IEnumerable<AddressHeader>) constructor throws an ArgumentException if one of the elements is null
. In the .NET Framework 4.7 and earlier versions, no exception is thrown.
Suggestion
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:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
</runtime>
</configuration>
Name | Value |
---|---|
Scope | Minor |
Version | 4.7.1 |
Type | Runtime |
Affected APIs
WCF MsmqSecureHashAlgorithm default value is now SHA256
Details
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.
Suggestion
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:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm=true" />
</runtime>
</configuration>
Name | Value |
---|---|
Scope | Minor |
Version | 4.7.1 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
WCF PipeConnection.GetHashAlgorithm now uses SHA256
Details
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.
Suggestion
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:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm=true" />
</runtime>
</configuration>
Name | Value |
---|---|
Scope | Minor |
Version | 4.7.1 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
Windows Presentation Foundation (WPF)
Chained Popups with StaysOpen=False
Details
A Popup with StaysOpen=False is supposed to close when you click outside the Popup. When two or more such Popups are chained (i.e. one contains another), there were many problems, including:
- Open two levels, click outside P2 but inside P1. Nothing happens.
- Open two levels, click outside P1. Both popups close.
- Open and close two levels. Then try to open P2 again. Nothing happens.
- Try to open three levels. You can't. (Either nothing happens or the first two levels close, depending on where you click.)
These cases (and other variants) now work as expected.
Name | Value |
---|---|
Scope | Edge |
Version | 4.7.1 |
Type | Runtime |
Affected APIs
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
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
Data Binding improvement for KeyedCollection
Details
Fixed Binding incorrect use of IList indexer when the source object declares a custom indexer with the same signature (for example, KeyedCollection<int,TItem>).
Suggestion
In order for an application that targets an older version to benefit from this change, it must run on the .NET Framework 4.8 or later, and it must opt in to the change by adding the following AppContext switch to the <runtime>
section of the app config file and setting it to false
:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false -->
<AppContextSwitchOverrides value="Switch.System.Windows.Data.Binding.IListIndexerHidesCustomIndexer=false" />
</runtime>
</configuration>
Name | Value |
---|---|
Scope | Major |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
Fixed a issue when ListBox stops responding if it contains duplicate value-types
Details
Fixed a problem where a virtualizing ItemsControl can stop responding during scrolling when its Items
collection contains duplicate value-typed objects.
Name | Value |
---|---|
Scope | Major |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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
Improvements to Grid star-rows space allocating algorithm
Details
Fixed a bug in the algorithm for allocating sizes to) in a Grid introduced in .NET Framework 4.7. In some cases, such as a Grid with Height="Auto"
containing empty rows, rows were arranged at the wrong position, possibly outside the Grid altogether.
Suggestion
In order for the application to benefit from these changes, it must run on the .NET Framework 4.8 or later.
Name | Value |
---|---|
Scope | Major |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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
Keyboard navigation improvement in ListBox with Hyperlinks
Details
Fixed incorrect result of pressing an arrow key when the focus is on a hyperlink within an item that is not the selected item of the parent ItemsControl.
Name | Value |
---|---|
Scope | Major |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
Keytips behavior improved in WPF
Details
Keytips behavior has been modified to bring parity with behavior on Microsoft Word and Windows Explorer. By checking whether keytip state is enabled or not in the case of a SystemKey (in particular, Key or F11) being pressed, WPF handles keytip keys appropriately. Keytips now dismiss a menu even when it is opened by mouse.
Suggestion
N/A
Name | Value |
---|---|
Scope | Edge |
Version | 4.7.2 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
Performance improvement in Automation tree for grouping ItemsControls
Details
Improved the performance of rebuilding the automation tree of an ItemsControl, such as a ListBox or DataGrid, in which grouping is enabled.
Name | Value |
---|---|
Scope | Major |
Version | 4.8 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
Feedback
Submit and view feedback for