Runtime Changes for Migration from .NET Framework 4.5 to 4.8

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

ADO.NET

ADO.NET now attempts to automatically reconnect broken SQL connections

Details

Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.

Suggestion

If this feature is undesirable due to compatibility concerns, it can be disabled by setting the System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount property of a connection string (or System.Data.SqlClient.SqlConnectionStringBuilder) to 0.

Name Value
Scope Edge
Version 4.5.1
Type Runtime

Affected APIs

-IDbConnection.ConnectionString

  • SqlConnection.ConnectionString
  • ConnectionStringSettings.ConnectionString
  • DbConnection.ConnectionString
  • DbConnectionStringBuilder.ConnectionString
  • SqlConnectionStringBuilder()
  • SqlConnectionStringBuilder(String)
  • DbConnectionStringBuilder()
  • DbConnectionStringBuilder(Boolean)
  • |

    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

    -System.Web.UI.WebControls.CheckBox|

    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

    -HttpRequest.Form

  • HttpRequest.Files
  • HttpRequest.ContentEncoding
  • |

    ASP.NET MVC now escapes spaces in strings passed in via route parameters

    Details

    In order to conform to RFC 2396, spaces in route paths are now escaped when populating action parameters from a route. So, whereas /controller/action/some data would previously match the route /controller/action/{data} and provide some data as the data parameter, it will now provide some%20data instead.

    Suggestion

    Code should be updated to unescape string parameters from a route. If the original URI is needed, it can be accessed with the RequestUri.OriginalString API.

    Name Value
    Scope Minor
    Version 4.5.2
    Type Runtime

    Affected APIs

    -RouteAttribute(String)|

    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

    -ValidationContext.MemberName|

    GridViews with AllowCustomPaging set to true may fire the PageIndexChanging event when leaving the final page of the view

    Details

    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.

    Suggestion

    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

    Affected APIs

    -GridView.AllowCustomPaging|

    No longer able to set EnableViewStateMac to false

    Details

    ASP.NET no longer allows developers to specify <pages enableViewStateMac="false"/> or <@Page EnableViewStateMac="false" %>. The view state message authentication code (MAC) is now enforced for all requests with embedded view state. Only apps that explicitly set the EnableViewStateMac property to false are affected.

    Suggestion

    EnableViewStateMac must be assumed to be true, and any resulting MAC errors must be resolved (as explained in this guidance, which contains multiple resolutions depending on the specifics of what is causing MAC errors).

    Name Value
    Scope Major
    Version 4.5.2
    Type Runtime

    Profiling ASP.Net MVC4 apps can lead to Fatal Execution Engine Error

    Details

    Profilers using NGEN /Profile assemblies may crash profiled ASP.NET MVC4 applications on startup with a 'Fatal Execution Engine Exception'

    Suggestion

    This issue is fixed in the .NET Framework 4.5.2. Alternatively, the profiler may avoid this issue by specifying COR_PRF_DISABLE_ALL_NGEN_IMAGES in its event mask.

    Name Value
    Scope Edge
    Version 4.5
    Type Runtime

    Core

    .NET COM successfully marshals ByRef SafeArray parameters on events

    Details

    In the .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

    .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 the .NET Framework 4.8. In previous versions of the .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=1This 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.NETFrameworkThen add the following:Value name: DisableCCWSupportIAgileObject Type: DWORD (32-bit) Value (also called REG_WORD) Value: 1You 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

    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

    -System.Uri|

    AppDomainSetup.DynamicBase is no longer randomized by UseRandomizedStringHashAlgorithm

    Details

    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.

    Suggestion

    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

    Affected APIs

    -AppDomainSetup.DynamicBase|

    Calling Attribute.GetCustomAttributes on an indexer property no longer throws AmbiguousMatchException if the ambiguity can be resolved by index's type

    Details

    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.

    Suggestion

    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

    Affected APIs

    -Attribute.GetCustomAttribute(MemberInfo, Type)

  • Attribute.GetCustomAttribute(MemberInfo, Type, Boolean)
  • Attribute.GetCustomAttributes(MemberInfo)
  • Attribute.GetCustomAttributes(MemberInfo, Boolean)
  • Attribute.GetCustomAttributes(MemberInfo, Type)
  • Attribute.GetCustomAttributes(MemberInfo, Type, Boolean)
  • CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type)
  • CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type, Boolean)
  • CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo)
  • CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo, Boolean)
  • CustomAttributeExtensions.GetCustomAttributes(MemberInfo)
  • CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Boolean)
  • CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type)
  • CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type, Boolean)
  • CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo)
  • CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo, Boolean)
  • |

    ConcurrentQueue<T>.TryPeek can return an erroneous null via its out parameter

    Details

    In some multi-threaded scenarios, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) can return true, but populate the out parameter with a null value (instead of the correct, peeked value).

    Suggestion

    This issue is fixed in the .NET Framework 4.5.1. Upgrading to that Framework will solve the issue.

    Name Value
    Scope Major
    Version 4.5
    Type Runtime

    Affected APIs

    -ConcurrentQueue<T>.TryPeek(T)|

    Deserialization of objects across appdomains can fail

    Details

    In some cases, when an app uses two or more app domains with different application bases, trying to deserialize objects in the logical call context across app domains throws an exception.

    Suggestion

    See Mitigation: Deserialization of Objects Across App Domains

    Name Value
    Scope Edge
    Version 4.5.1
    Type Runtime

    ETW EventListeners do not capture events from providers with explicit keywords (like the TPL provider)

    Details

    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.

    Suggestion

    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

    Affected APIs

    -EventListener.EnableEvents(EventSource, EventLevel)|

    EventListener truncates strings with embedded nulls

    Details

    System.Diagnostics.Tracing.EventListener truncates strings with embedded nulls. Null characters are not supported by the System.Diagnostics.Tracing.EventSource class. The change only affects apps that use System.Diagnostics.Tracing.EventListener to read System.Diagnostics.Tracing.EventSource data in process and that use null characters as delimiters.

    Suggestion

    System.Diagnostics.Tracing.EventSource data should be updated, if possible, to not use embedded null characters.

    Name Value
    Scope Edge
    Version 4.5.1
    Type Runtime

    Affected APIs

    -EventListener()

  • EventListener.EnableEvents(EventSource, EventLevel)
  • EventListener.EnableEvents(EventSource, EventLevel, EventKeywords)
  • EventListener.EnableEvents(EventSource, EventLevel, EventKeywords, IDictionary<String,String>)
  • |

    EventSource.WriteEvent impls must pass WriteEvent the same parameters that it received (plus ID)

    Details

    The runtime now enforces the contract that specifies the following: A class derived from System.Diagnostics.Tracing.EventSource that defines an ETW event method must call the base class EventSource.WriteEvent method with the event ID followed by the same arguments that the ETW event method was passed.

    Suggestion

    An System.IndexOutOfRangeException exception is thrown if an System.Diagnostics.Tracing.EventListener reads System.Diagnostics.Tracing.EventSource data in process for an event source that violates this contract.

    Name Value
    Scope Minor
    Version 4.5.1
    Type Runtime

    Marshal.SizeOf and Marshal.PtrToStructure overloads break dynamic code

    Details

    Beginning in the .NET Framework 4.5.1, dynamically binding to the methods SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr), or PtrToStructure<T>(IntPtr, T), (via Windows PowerShell, IronPython, or the C# dynamic keyword, for example) can result in MethodInvocationExceptions because new overloads of these methods have been added that may be ambiguous to the scripting engines.

    Suggestion

    Update scripts to clearly indicate which overload should be used. This can typically done by explicitly casting the methods' type parameters as Type. See this link for more detail and examples of how to workaround the issue.

    Name Value
    Scope Minor
    Version 4.5.1
    Type Runtime

    Persian calendar now uses the Hijri solar algorithm

    Details

    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.

    Suggestion

    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

    Affected APIs

    -System.Globalization.PersianCalendar|

    Reflection objects can no longer be passed from managed code to out-of-process DCOM clients

    Details

    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.

    Suggestion

    Update marshaling code to work with non-reflection objects

    Name Value
    Scope Minor
    Version 4.6
    Type Runtime

    Some .NET APIs cause first chance (handled) EntryPointNotFoundExceptions

    Details

    In the .NET Framework 4.5, a small number of .NET methods began throwing first chance System.EntryPointNotFoundExceptions. These exceptions were handled within the .NET Framework, but could break test automation that did not expect the first chance exceptions. These same APIs break some ApiVerifier scenarios when HighVersionLie is enabled.

    Suggestion

    This bug can be avoided by upgrading to .NET Framework 4.5.1. Alternatively, test automation can be updated to not break on first-chance System.EntryPointNotFoundExceptions.

    Name Value
    Scope Edge
    Version 4.5
    Type Runtime

    Affected APIs

    -Debug.Assert(Boolean)

  • Debug.Assert(Boolean, String)
  • Debug.Assert(Boolean, String, String)
  • Debug.Assert(Boolean, String, String, Object[])
  • XmlSerializer(Type)
  • |

    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

    -Uri.TryCreate(Uri, Uri, Uri)

  • Uri.TryCreate(String, UriKind, Uri)
  • Uri.TryCreate(Uri, String, Uri)
  • |

    TargetFrameworkName for default app domain no longer defaults to null if not set

    Details

    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.

    Suggestion

    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

    Affected APIs

    -AppDomainSetup.TargetFrameworkName|

    WinRT stream adapters no long call FlushAsync automatically on close

    Details

    In Windows Store apps, Windows Runtime stream adapters no longer call the FlushAsync method from the Dispose method.

    Suggestion

    This change should be transparent. Developers can restore the previous behavior by writing code like this:

    using (var stream = GetWindowsRuntimeStream() as Stream)
    {
    // do something
    await stream.FlushAsync();
    }
    

    Name Value
    Scope Transparent
    Version 4.5.1
    Type Runtime

    X509Certificate2.ToString(Boolean) does not throw now when .NET cannot handle the certificate

    Details

    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.

    Suggestion

    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

    Affected APIs

    -X509Certificate2.ToString(Boolean)|

    Data

    ADO.NET now attempts to automatically reconnect broken SQL connections

    Details

    Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.

    Suggestion

    If this feature is undesirable due to compatibility concerns, it can be disabled by setting the System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount property of a connection string (or System.Data.SqlClient.SqlConnectionStringBuilder) to 0.

    Name Value
    Scope Edge
    Version 4.5.1
    Type Runtime

    Affected APIs

    -IDbConnection.ConnectionString

  • SqlConnection.ConnectionString
  • ConnectionStringSettings.ConnectionString
  • DbConnection.ConnectionString
  • DbConnectionStringBuilder.ConnectionString
  • SqlConnectionStringBuilder()
  • SqlConnectionStringBuilder(String)
  • DbConnectionStringBuilder()
  • DbConnectionStringBuilder(Boolean)
  • |

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

    SqlConnection.Open fails on Windows 7 with non-IFS Winsock BSP or LSP present

    Details

    Open() and OpenAsync(CancellationToken) fail in the .NET Framework 4.5 if running on a Windows 7 machine with a non-IFS Winsock BSP or LSP are present on the computer.To determine whether a non-IFS BSP or LSP is installed, use the netsh WinSock Show Catalog command, and examine every Winsock Catalog Provider Entry item that is returned. If the Service Flags value has the 0x20000 bit set, the provider uses IFS handles and will work correctly. If the 0x20000 bit is clear (not set), it is a non-IFS BSP or LSP.

    Suggestion

    This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. Alternatively, it can be avoided by removing any installed non-IFS Winsock LSPs.

    Name Value
    Scope Minor
    Version 4.5
    Type Runtime

    Affected APIs

    -SqlConnection.Open()

  • SqlConnection.OpenAsync(CancellationToken)
  • |

    Debugger

    Null coalescer values are not visible in debugger until one step later

    Details

    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.

    Suggestion

    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

    Entity Framework

    EF no longer throws for QueryViews with specific characteristics

    Details

    Entity Framework no longer throws a System.StackOverflowException exception when an app executes a query that involves a QueryView with a 0..1 navigation property that attempts to include the related entities as part of the query. For example, by calling .Include(e => e.RelatedNavProp).

    Suggestion

    This change only affects code that uses QueryViews with 1-0..1 relationships when running queries that call .Include. It improves reliability and should be transparent to almost all apps. However, if it causes unexpected behavior, you can disable it by adding the following entry to the <appSettings> section of the app's configuration file:

    <add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />
    

    Name Value
    Scope Edge
    Version 4.5.2
    Type Runtime

    Opt-in break to revert from different 4.5 SQL generation to simpler 4.0 SQL generation

    Details

    Queries that produce JOIN statements and contain a call to a limiting operation without first using OrderBy now produce simpler SQL. After upgrading to .NET Framework 4.5, these queries produced more complicated SQL than previous versions.

    Suggestion

    This feature is disabled by default. If Entity Framework generates extra JOIN statements that cause performance degradation, you can enable this feature by adding the following entry to the <appSettings> section of the application configuration (app.config) file:

    <add key="EntityFramework_SimplifyLimitOperations" value="true" />
    

    Name Value
    Scope Transparent
    Version 4.5.2
    Type Runtime

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

    Networking

    ContentDisposition DateTimes returns slightly different string

    Details

    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.

    Suggestion

    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

    Affected APIs

    -ContentDisposition.ToString()

  • ContentDisposition.GetHashCode()
  • |

    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.
    • How to opt out of the change: If you can't update the certificate, you can work around the breaking change temporarily with the following configration 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

    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

    -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
  • |

    Serialization

    Exception message has changed for failed DataContract serialization in case of an unknown type

    Details

    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.

    Suggestion

    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

    Affected APIs

    -DataContractJsonSerializer(Type)

  • DataContractJsonSerializer(Type, IEnumerable<Type>)
  • DataContractJsonSerializer(Type, DataContractJsonSerializerSettings)
  • DataContractJsonSerializer(Type, String)
  • DataContractJsonSerializer(Type, String, IEnumerable<Type>)
  • DataContractJsonSerializer(Type, XmlDictionaryString)
  • DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>)
  • DataContractJsonSerializer(Type, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
  • DataContractJsonSerializer(Type, String, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
  • DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
  • DataContractSerializer(Type)
  • DataContractSerializer(Type, DataContractSerializerSettings)
  • DataContractSerializer(Type, IEnumerable<Type>)
  • DataContractSerializer(Type, String, String)
  • DataContractSerializer(Type, String, String, IEnumerable<Type>)
  • DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString)
  • DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>)
  • DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
  • DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
  • DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
  • DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
  • DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
  • DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
  • |

    NetDataContractSerializer fails to deserialize a ConcurrentDictionary serialized with a different .NET version

    Details

    By design, the System.Runtime.Serialization.NetDataContractSerializer can be used only if both the serializing and deserializing ends share the same CLR types. Therefore, it is not guaranteed that an object serialized with one version of the .NET Framework can be deserialized by a different version.System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> is a type that is known to not to deserialize correctly if serialized with the .NET Framework 4.5 or earlier and deserialized with the .NET Framework 4.5.1 or later.

    Suggestion

    There are a number of possible work-arounds for this issue:

    Name Value
    Scope Minor
    Version 4.5.1
    Type Runtime

    Affected APIs

    -NetDataContractSerializer.Deserialize(Stream)|

    Setup and Deployment

    Product versioning changes in the .NET Framework 4.6 and later versions

    Details

    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:

    • The value of the 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.
    • The file and product versioning for .NET Framework files has changed from the earlier versioning scheme of 4.0.30319.x to 4.6.X.0 for the .NET Framework 4.6 and its point releases, and to 4.7.X.0 for the .NET Framework 4.7 and 4.7.1. You can see these new values when you view the file's Properties after right-clicking on a file.
    • The AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute attributes for managed assemblies have Version values in the form 4.6.X.0 for the .NET Framework 4.6 and its point releases, and 4.7.X.0 for the .NET Framework 4.7 and 4.7.1.
    • In the .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1, the Environment.Version property returns the fixed version string 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.

    Suggestion

    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:

    [!IMPORTANT] The subkey name is NET Framework Setup, not .NET Framework Setup.
    • To determine the directory path to the .NET Framework common language runtime, call the RuntimeEnvironment.GetRuntimeDirectory() method.
    • To get the CLR version, call the RuntimeEnvironment.GetSystemVersion() method. For the .NET Framework 4 and its point releases (the .NET Framework 4.5, 4.5.1, 4.5.2, and .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1), it returns the string v4.0.30319.

    Name Value
    Scope Minor
    Version 4.6
    Type Runtime

    The .NET Framework 4.6 does not use a 4.5.x.x version when registering itself in the registry

    Details

    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.

    Suggestion

    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

    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.IsNullOrWhteSpace(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

    -Contract.Invariant(Boolean)

  • Contract.Requires(Boolean)
  • |

    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

    Windows Communication Foundation (WCF)

    MinFreeMemoryPercentageToActiveService is now respected

    Details

    This setting establishes the minimum memory that must be available on the server before a WCF service can be activated. It is designed to prevent System.OutOfMemoryException exceptions. In the .NET Framework 4.5, this setting had no effect. In the .NET Framework 4.5.1, the setting is observed.

    Suggestion

    An exception occurs if the free memory available on the web server is less than the percentage defined by the configuration setting. Some WCF services that successfully started and ran in a constrained memory environment may now fail.

    Name Value
    Scope Minor
    Version 4.5.1
    Type Runtime

    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
  • |

    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

    • How to opt out of the change 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

    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

    -AddressHeaderCollection(IEnumerable<AddressHeader>)|

    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

    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

    WCF services that use NETTCP with SSL security and MD5 certificate authentication

    Details

    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.

    Suggestion

    You can work around this issue so that a WCF client can connect to a WCF server by doing any of the following:

    • Update the certificate to not use the MD5 algorithm. This is the recommended solution.
    • If the binding is not dynamically configured in source code, update the application's configuration file to use TLS 1.1 or an earlier version of the protocol. This allows you to continue to use a certificate with the MD5 hash algorithm.

    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

    Windows Presentation Foundation (WPF)

    Accessing a WPF DataGrid's selected items from a handler of the DataGrid's UnloadingRow event can cause a NullReferenceException

    Details

    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.

    Suggestion

    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

    Affected APIs

    -DataGrid.UnloadingRow

  • DataGrid.UnloadingRowDetails
  • |

    Calling DataGrid.CommitEdit from a CellEditEnding handler drops focus

    Details

    Calling CommitEdit() from one of the System.Windows.Controls.DataGrid's System.Windows.Controls.DataGrid.CellEditEnding event handlers causes the System.Windows.Controls.DataGrid to lose focus.

    Suggestion

    This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. Alternatively, it can be avoided by explicitly re-selecting the System.Windows.Controls.DataGrid after calling System.Windows.Controls.DataGrid.CommitEdit().

    Name Value
    Scope Edge
    Version 4.5
    Type Runtime

    Affected APIs

    -DataGrid.CommitEdit()

  • DataGrid.CommitEdit(DataGridEditingUnit, Boolean)
  • |

    Calling Items.Refresh on a WPF ListBox, ListView, or DataGrid with items selected can cause duplicate items to appear in the element

    Details

    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.

    Suggestion

    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.

    Name Value
    Scope Minor
    Version 4.5
    Type Runtime

    Affected APIs

    -CollectionView.Refresh()|

    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

    -Popup.StaysOpen|

    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|

    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

    Fixed a hang when ListBox contains duplicate value-types

    Details

    Fixed a problem where a virtualizingItemsControl can hang during scrolling when its Items collection contains duplicate value-typed objects.

    Name Value
    Scope Major
    Version 4.8
    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|

    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

    Intermittently unable to scroll to bottom item in ItemsControls (like ListBox and DataGrid) when using custom DataTemplates

    Details

    In some instances, a bug in the .NET Framework 4.5 is causing ItemsControls (like System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) to not scroll to their bottom item when using custom DataTemplates. If the scrolling is attempted a second time (after scrolling back up), it will work then.

    Suggestion

    This issue has been fixed in the .NET Framework 4.5.2 and may be addressed by upgrading to that version (or a later version) of the .NET Framework. Alternatively, users can still drag scroll bars to the final items in these collections, but may need to try twice to do so successfully.

    Name Value
    Scope Minor
    Version 4.5
    Type Runtime

    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|

    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

    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

    ListBoxItem IsSelected binding issue with ObservableCollection<T>.Move

    Details

    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.

    Suggestion

    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

    Affected APIs

    -ObservableCollection<T>.Move(Int32, Int32)

  • ObservableCollection<T>.MoveItem(Int32, Int32)
  • |

    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

    Right clicking on a WPF DataGrid row header changes the DataGrid selection

    Details

    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.

    Suggestion

    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

    Affected APIs

    -DataGrid()|

    Scrolling a WPF TreeView or grouped ListBox in a VirtualizingStackPanel can cause a hang

    Details

    In the .NET Framework v4.5, scrolling a WPF System.Windows.Controls.TreeView in a virtualized stack panel can cause hangs if there are margins in the viewport (between the items in the System.Windows.Controls.TreeView, for example, or on an ItemsPresenter element). Additionally, in some cases, different sized items in the view can cause instability even if there are no margins.

    Suggestion

    This bug can be avoided by upgrading to .NET Framework 4.5.1. Alternatively, margins can be removed from view collections (like System.Windows.Controls.TreeViews) within virtualized stack panels if all contained items are the same size.

    Name Value
    Scope Major
    Version 4.5
    Type Runtime

    Affected APIs

    -VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)|

    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 in text-enabled controls will not work in Windows 10 for languages not in the OS's input language list

    Details

    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.

    Suggestion

    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

    WPF windows are rendered without clipping when extending outside a single monitor

    Details

    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.

    Suggestion

    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

    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