Runtime Changes for Migration from .NET Framework 4.7 to 4.7.1
- (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)
If you are migrating from the .NET Framework 4.7 to 4.7.1, review the following topics for application compatibility issues that may affect your app:
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 |
Affected APIs
Not detectable via API analysis.
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)
Windows Communication Foundation (WCF)
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
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.Selectoris a collection with a custom implementation ofT:System.Collections.Specialized.INotifyCollectionChanged. - The selected item is removed from the collection.
- The
T:System.Collections.Specialized.NotifyCollectionChangedEventArgshasP:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex= -1 (indicating an unknown position).
Suggestion
Upgrade to .NET Framework 4.7.1.
| Name | Value |
|---|---|
| Scope | Minor |
| Version | 4.7 |
| Type | Runtime |
Affected APIs
Not detectable via API analysis.
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
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 |
Affected APIs
Not detectable via API analysis.