Events
Mar 17, 9 PM - Mar 21, 10 AM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
This article lists the app compatibility issues that were introduced in .NET Framework 4.6, 4.6.1, and 4.6.2.
A bug in the .NET Framework 4.5 causes System.Web.UI.WebControls.GridView.PageIndexChanging to sometimes not fire for System.Web.UI.WebControls.GridViews that have enabled System.Web.UI.WebControls.GridView.AllowCustomPaging.
This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework. As a work-around, the app can do an explicit BindGrid on any Page_Load
that would hit these conditions (the System.Web.UI.WebControls.GridView is on the last page and LastSystem.Web.UI.WebControls.GridView.PageSize is different from System.Web.UI.WebControls.GridView.PageSize). Alternatively, the app can be modified to allow paging (instead of custom paging), as that scenario does not demonstrate the problem.
Name | Value |
---|---|
Scope | Minor |
Version | 4.5 |
Type | Runtime |
Due to internal changes to the type, ConcurrentDictionary<TKey,TValue> objects that are serialized with the .NET Framework 4.5 using the System.Runtime.Serialization.NetDataContractSerializer cannot be deserialized in the .NET Framework 4.5.1 or in the .NET Framework 4.5.2.Note that moving in the other direction (serializing with the .NET Framework 4.5.x and deserializing with the .NET Framework 4.5) works. Similarly, all 4.x cross-version serialization works with the .NET Framework 4.6.Serializing and deserializing with a single version of the .NET Framework is not affected.
If it is necessary to serialize and deserialize a System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> between the .NET Framework 4.5 and .NET Framework 4.5.1/4.5.2, a different serializer like the System.Runtime.Serialization.DataContractSerializer should be used instead of the System.Runtime.Serialization.NetDataContractSerializer. Alternatively, because this issue is addressed in the .NET Framework 4.6, it may be solved by upgrading to that version of the .NET Framework.
Name | Value |
---|---|
Scope | Minor |
Version | 4.5.1 |
Type | Runtime |
Not detectable via API analysis.
Prior to the .NET Framework 4.6, the value of DynamicBase would be randomized between application domains, or between processes, if UseRandomizedStringHashAlgorithm was enabled in the app's config file. Beginning in the .NET Framework 4.6, DynamicBase will return a stable result between different instances of an app running, and between different app domains. Dynamic bases will still differ for different apps; this change only removes the random naming element for different instances of the same app.
Be aware that enabling UseRandomizedStringHashAlgorithm
will not result in DynamicBase being randomized. If a random base is needed, it must be produced in your app's code rather than via this API.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
Prior to the .NET Framework 4.6, calling GetCustomAttribute(s)
on an indexer property which differed from another property only by the type of the index would result in an System.Reflection.AmbiguousMatchException. Beginning in the .NET Framework 4.6, the property's attributes will be correctly returned.
Be aware that GetCustomAttribute(s) will work more frequently now. If an app was previously relying on the System.Reflection.AmbiguousMatchException, reflection should now be used to explicitly look for multiple indexers, instead.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
In the .NET Framework v4.5.1, the profiling API RootReferences2()
is incorrectly never returning COR_PRF_GC_ROOT_HANDLE
(they are returned as COR_PRF_GC_ROOT_OTHER
instead). This issue is fixed beginning in the .NET Framework 4.6.
This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
Name | Value |
---|---|
Scope | Minor |
Version | 4.5.1 |
Type | Runtime |
Not detectable via API analysis.
ETW EventListeners with a blank keyword mask do not properly capture events from providers with explicit keywords. In the .NET Framework 4.5, the TPL provider began providing explicit keywords and triggered this issue. In the .NET Framework 4.6, EventListeners have been updated to no longer have this issue.
To work around this problem, replace calls to EnableEvents(EventSource, EventLevel) with calls to the EnableEvents overload that explicitly specifies the "any keywords" mask to use: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))
.
Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
Name | Value |
---|---|
Scope | Edge |
Version | 4.5 |
Type | Runtime |
Starting with the .NET Framework 4.6, the System.Globalization.PersianCalendar class uses the Hijri solar algorithm. Converting dates between the System.Globalization.PersianCalendar and other calendars may produce a slightly different result beginning with the .NET Framework 4.6 for dates earlier than 1800 or later than 2023 (Gregorian).Also, PersianCalendar.MinSupportedDateTime is now March 22, 0622
instead of March 21, 0622
.
Be aware that some early or late dates may be slightly different when using the PersianCalendar in .NET Framework 4.6. Also, when serializing dates between processes which may run on different .NET Framework versions, do not store them as PersianCalendar date strings (since those values may be different).
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Reflection objects can no longer be passed from managed code to out-of-process DCOM clients. The following types are affected:
Calls to IMarshal
for the object return E_NOINTERFACE
.
Update marshaling code to work with non-reflection objects.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
The System.AppDomainSetup.TargetFrameworkName was previously null in the default app domain, unless it was explicitly set. Beginning in 4.6, the System.AppDomainSetup.TargetFrameworkName property for the default app domain will have a default value derived from the TargetFrameworkAttribute (if one is present). Non-default app domains will continue to inherit their System.AppDomainSetup.TargetFrameworkName from the default app domain (which will not default to null in 4.6) unless it is explicitly overridden.
Code should be updated to not depend on TargetFrameworkName defaulting to null. If it is required that this property continue to evaluate to null, it can be explicitly set to that value.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
In .NET Framework 4.5.2 and earlier versions, this method would throw if true
was passed for the verbose parameter and there were certificates installed that weren't supported by the .NET Framework. Now, the method will succeed and return a valid string that omits the inaccessible portions of the certificate.
Any code depending on X509Certificate2.ToString(Boolean) should be updated to expect that the returned string may exclude some certificate data (such as public key, private key, and extensions) in some cases in which the API would have previously thrown.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
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 database that resolves to localhost
, upgrade to the .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
A bug in the .NET Framework 4.5 causes values set via a null coalescing operation to not be visible in the debugger immediately after the assignment operation is executed when running on the 64-bit version of the Framework.
Stepping one additional time in the debugger will cause the local/field's value to be correctly updated. Also, this issue has been fixed in the .NET Framework 4.6; upgrading to that version of the Framework should solve the issue.
Name | Value |
---|---|
Scope | Edge |
Version | 4.5 |
Type | Runtime |
Not detectable via API analysis.
String representations of System.Net.Mime.ContentDisposition's have been updated, beginning in 4.6, to always represent the hour component of a System.DateTime with two digits. This is to comply with RFC822 and RFC2822. This causes ToString() to return a slightly different string in 4.6 in scenarios where one of the disposition's time elements was before 10:00 AM. Note that ContentDispositions are sometimes serialized via converting them to strings, so any ToString() operations, serialization, or GetHashCode calls should be reviewed.
Do not expect that string representations of ContentDispositions from different .NET Framework versions will correctly compare to one another. Convert the strings back to ContentDispositions, if possible, before conducting a comparison.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Beginning in the .NET Framework 4.6, the exception message given if a System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Json.DataContractJsonSerializer fails to serialize or deserialize due to missing 'known types' has been clarified.
Apps should not depend on specific exception messages. If an app depends on this message, either update it to expect the new message or (preferably) change it to depend only on the exception type.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
Product versioning has changed from the previous releases of the .NET Framework, and particularly from the .NET Framework 4, 4.5, 4.5.1, and 4.5.2. The following are the detailed changes:
Version
entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
key has changed to 4.6.xxxxx
for the .NET Framework 4.6 and its point releases, and to 4.7.xxxxx
for the .NET Framework 4.7 and 4.7.1. In the .NET Framework 4.5, 4.5.1, and 4.5.2, it had the format 4.5.xxxxx
.4.0.30319.42000
. In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format 4.0.30319.xxxxx
(for example, "4.0.30319.18010"). Note that we do not recommend application code taking any new dependency on the Environment.Version property.For more information, see How to: Determine which .NET Framework Versions Are Installed.
In general, applications should depend on the recommended techniques for detecting such things as the runtime version of the .NET Framework and the installation directory:
InstallPath
entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
key.Important
The subkey name is NET Framework Setup
, not .NET Framework Setup
.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
As one might expect, the version key set in the registry (at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full
) for the .NET Framework 4.6 begins with '4.6', not '4.5'. Apps that depend on these registry keys to know which .NET Framework versions are installed on a machine should be updated to understand that 4.6 is a new possible version, and one that is compatible with previous 4.5.x releases.
Update apps probing for a .NET Framework 4.5 install by looking for 4.5 registry keys to also accept 4.6.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
The .NET Framework 4.6 adds TLS 1.1 and TLS 1.2 to the WCF SSL default protocol list. When both client and server machines have the .NET Framework 4.6 or later installed, TLS 1.2 is used for negotiation.TLS 1.2 does not support MD5 certificate authentication. As a result, if a customer uses an MD5 certificate, the WCF client will fail to connect to the WCF service.
You can work around this issue so that a WCF client can connect to a WCF server by doing any of the following:
Warning
This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.
The following configuration file does this:
<configuration>
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding>
<security mode= "None/Transport/Message/TransportWithMessageCredential" >
<transport clientCredentialType="None/Windows/Certificate"
protectionLevel="None/Sign/EncryptAndSign"
sslProtocols="Ssl3/Tls1/Tls11">
</transport>
</security>
</binding>
</netTcpBinding>
</bindings>
</system.ServiceModel>
</configuration>
Warning
This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
Due to a bug in the .NET Framework 4.5, event handlers for DataGrid events involving the removal of a row can cause a System.NullReferenceException to be thrown if they access the DataGrid's System.Windows.Controls.Primitives.Selector.SelectedItem or System.Windows.Controls.Primitives.MultiSelector.SelectedItems properties.
This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
Name | Value |
---|---|
Scope | Minor |
Version | 4.5 |
Type | Runtime |
In the .NET Framework 4.5, calling ListBox.Items.Refresh from code while items are selected in a System.Windows.Controls.ListBox can cause the selected items to be duplicated in the list. A similar issue occurs with System.Windows.Controls.ListView and System.Windows.Controls.DataGrid. This is fixed in the .NET Framework 4.6.
This issue may be worked around by programmatically unselecting items before System.Windows.Data.CollectionView.Refresh() is called and then re-selecting them after the call is completed. Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
Value | |
---|---|
Scope | Minor |
Version | 4.5 |
Type | Runtime |
Certain sequences of actions involving a System.Windows.Controls.ComboBox and its data source can result in a System.NullReferenceException.
If possible, upgrade to .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Calling Move(Int32, Int32) or MoveItem(Int32, Int32) on a collection bound to a System.Windows.Controls.ListBox with items selected can lead to erratic behavior with future selection or unselection of System.Windows.Controls.ListBox items.
Calling System.Collections.ObjectModel.Collection<T>.Remove(T) and System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) instead of Move(Int32, Int32) will work around this issue. Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
Name | Value |
---|---|
Scope | Minor |
Version | 4.5 |
Type | Runtime |
Right-clicking a selected System.Windows.Controls.DataGrid row header while multiple rows are selected results in the System.Windows.Controls.DataGrid's selection changing to only that row.
This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
Name | Value |
---|---|
Scope | Edge |
Version | 4.5 |
Type | Runtime |
An issue was introduced in 4.5.2 that causes wisptis.exe
to be spawned that can freeze mouse input.
A fix for this issue is available in a servicing release of the .NET Framework 4.5.2 (hotfix rollup 3026376), or by upgrading to the .NET Framework 4.6
Name | Value |
---|---|
Scope | Major |
Version | 4.5.2 |
Type | Runtime |
Not detectable via API analysis.
When running on Windows 10, the spell checker may not work for WPF text-enabled controls because platform spell-checking capabilities are available only for languages present in the input languages list.In Windows 10, when a language is added to the list of available keyboards, Windows automatically downloads and installs a corresponding Feature on Demand (FOD) package that provides spell-checking capabilities. By adding the language to the input languages list, the spell checker will be supported.
Be aware that the language or text to be spell-checked must be added as an input language for spell-checking to work in Windows 10.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
In the .NET Framework 4.6 running on Windows 8 and above, the entire window is rendered without clipping when it extends outside of single display in a multi-monitor scenario. This is different from previous versions of the .NET Framework which would clip WPF windows that extended beyond a single display.
This behavior (whether to clip or not) can be explicitly set using the <EnableMultiMonitorDisplayClipping>
element in <appSettings>
in an application's configuration file, or by setting the EnableMultiMonitorDisplayClipping
property at app startup.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
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.
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 |
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. 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.
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:
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.1 |
Type | Runtime |
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.
Upgrade to .NET Framework 4.7
Name | Value |
---|---|
Scope | Edge |
Version | 4.6.1 |
Type | Runtime |
Not detectable via API analysis.
This includes a number of WPF Spell Checker issues:
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 |
Not detectable via API analysis.
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 database that resolves to localhost
, upgrade to the .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Not detectable via API analysis.
Starting with .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 .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 rethrows 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, you can configure the connection pool blocking period by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property introduced in .NET Framework 4.6.2. The value of the property is a member of the System.Data.SqlClient.PoolBlockingPeriod enumeration that can take any of three values:
You can restore the previous behavior by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property to AlwaysBlock.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.2 |
Type | Runtime |
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.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.2 |
Type | Runtime |
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.
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 |
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.
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 |
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:
id
attribute and a signature targets one of those elements as the root of the signature, the document will now be considered invalid.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 |
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.
Name | Value |
---|---|
Scope | Edge |
Version | 4.6.2 |
Type | Runtime |
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.
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 |
Certain sequences of actions involving a System.Windows.Controls.ComboBox and its data source can result in a System.NullReferenceException.
If possible, upgrade to .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
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.
Any one of the following:
Name | Value |
---|---|
Scope | Edge |
Version | 4.6.2 |
Type | Runtime |
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).
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 |
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.
Upgrade if possible to .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.5 |
Type | Runtime |
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. 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.
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:
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.1 |
Type | Runtime |
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.
Upgrade to .NET Framework 4.7
Name | Value |
---|---|
Scope | Edge |
Version | 4.6.2 |
Type | Runtime |
Not detectable via API analysis.
This includes a number of WPF Spell Checker issues:
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 |
Not detectable via API analysis.
.NET feedback
.NET is an open source project. Select a link to provide feedback:
Events
Mar 17, 9 PM - Mar 21, 10 AM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowTraining
Learning path
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization