Runtime Changes for Migration from .NET Framework 4.6.2 to 4.7
- (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.2 to 4.7, 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.
Windows Presentation Foundation (WPF)
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).
The exception's call stack 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 |
Affected APIs
Not detectable via API analysis.
DataGridCellsPanel.BringIndexIntoView throws ArgumentOutOfRangeException
Details
ScrollIntoView(Object) will work asynchronously when column virtualization is enabled but the column widths have not yet been determined. If columns are removed before the asynchronous work happens, an System.ArgumentOutOfRangeException can occur.
Suggestion
Any one of the following:
- Upgrade to .NET Framework 4.7.
- Install the latest servicing patch for .NET Framework 4.6.2.
- Avoid removing columns until the asynchronous response to ScrollIntoView(Object) has completed.
| Name | Value |
|---|---|
| Scope | Edge |
| Version | 4.6.2 |
| Type | Runtime |
Affected APIs
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 |
Affected APIs
Not detectable via API analysis.
Resizing a Grid can cause the application to become unresponsive
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 |
Affected APIs
Not detectable via API analysis.
RibbonGroup background is set to transparent in localized builds
Details
System.Windows.Controls.Ribbon.RibbonGroup background on localized builds was always painted with Transparent brush, resulting in poor UI experience. This is fixed in .NET Framework 4.7 WPF fix by updating the localized resources for System.Windows.Controls.Ribbon.RibbonGroup, which in turn ensures that the correct brush is selected.
Suggestion
Upgrade to .NET Framework 4.7
| Name | Value |
|---|---|
| Scope | Edge |
| Version | 4.6.2 |
| 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.
Povratne informacije
Pošalјite i prikažite povratne informacije za