Runtime Changes for Migration from .NET Framework 4.5.1 to 4.6.1
- (4.0 | 4.5)
- (4.0 | 4.5.1)
- (4.0 | 4.5.2)
- (4.0 | 4.6)
- (4.0 | 4.6.1)
- (4.0 | 4.6.2)
- (4.0 | 4.7)
- (4.0 | 4.7.1)
- (4.0 | 4.7.2)
- (4.0 | 4.8)
- (4.5 | 4.5.1)
- (4.5 | 4.5.2)
- (4.5 | 4.6)
- (4.5 | 4.6.1)
- (4.5 | 4.6.2)
- (4.5 | 4.7)
- (4.5 | 4.7.1)
- (4.5 | 4.7.2)
- (4.5 | 4.8)
- (4.5.1 | 4.5.2)
- (4.5.1 | 4.6)
- (4.5.1 | 4.6.1)
- (4.5.1 | 4.6.2)
- (4.5.1 | 4.7)
- (4.5.1 | 4.7.1)
- (4.5.1 | 4.7.2)
- (4.5.1 | 4.8)
- (4.5.2 | 4.6)
- (4.5.2 | 4.6.1)
- (4.5.2 | 4.6.2)
- (4.5.2 | 4.7)
- (4.5.2 | 4.7.1)
- (4.5.2 | 4.7.2)
- (4.5.2 | 4.8)
- (4.6 | 4.6.1)
- (4.6 | 4.6.2)
- (4.6 | 4.7)
- (4.6 | 4.7.1)
- (4.6 | 4.7.2)
- (4.6 | 4.8)
- (4.6.1 | 4.6.2)
- (4.6.1 | 4.7)
- (4.6.1 | 4.7.1)
- (4.6.1 | 4.7.2)
- (4.6.1 | 4.8)
- (4.6.2 | 4.7)
- (4.6.2 | 4.7.1)
- (4.6.2 | 4.7.2)
- (4.6.2 | 4.8)
- (4.7 | 4.7.1)
- (4.7 | 4.7.2)
- (4.7 | 4.8)
- (4.7.1 | 4.7.2)
- (4.7.1 | 4.8)
- (4.7.2 | 4.8)
- (4.8 | 4.8.1)
If you are migrating from the .NET Framework 4.5.1 to 4.6.1, review the following topics for application compatibility issues that may affect your app:
ASP.NET
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
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
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
Core
A ConcurrentDictionary serialized in .NET Framework 4.5 with NetDataContractSerializer cannot be deserialized by .NET Framework 4.5.1 or 4.5.2
Details
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.
Suggestion
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 |
Affected APIs
Not detectable via API analysis.
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
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)
COR_PRF_GC_ROOT_HANDLEs are not being enumerated by profilers
Details
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.
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.1 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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
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
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:
- System.Reflection.Assembly
- System.Reflection.MemberInfo (and its derived types, including System.Reflection.FieldInfo, System.Reflection.MethodInfo, System.Type, and System.Reflection.TypeInfo)
- System.Reflection.MethodBody
- System.Reflection.Module
- System.Reflection.ParameterInfo
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 |
Affected APIs
- System.Reflection.Assembly
- System.Reflection.FieldInfo
- System.Reflection.MemberInfo
- System.Reflection.MethodBody
- System.Reflection.MethodInfo
- System.Reflection.Module
- System.Reflection.ParameterInfo
- System.Reflection.TypeInfo
- System.Type
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
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
Data
Attempting a TCP/IP connection to a SQL Server database that resolves to localhost
fails
Details
In the .NET Framework 4.6 and 4.6.1, attempting a TCP/IP connection to a SQL Server database that resolves to localhost
fails with the error, "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"
Suggestion
This issue has been addressed and the previous behavior restored in the .NET Framework 4.6.2. To connect to a SQL Server database that resolves to localhost
, upgrade to the .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
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
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)
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 theHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
key has changed to4.6.xxxxx
for the .NET Framework 4.6 and its point releases, and to4.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 format4.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 format4.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:
- To detect the runtime version of the .NET Framework, see How to: Determine Which .NET Framework Versions Are Installed.
- To determine the installation path for the .NET Framework, use the value of the
InstallPath
entry in theHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
key.
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
Tools
Contract.Invariant or Contract.Requires<TException> do not consider String.IsNullOrEmpty to be pure
Details
For apps that target the .NET Framework 4.6.1, if the invariant contract for Contract.Invariant or the precondition contract for Requires calls the String.IsNullOrEmpty method, the rewriter emits compiler warning CC1036: "Detected call to method 'System.String.IsNullOrWhiteSpace(System.String)' without [Pure] in method." This is a compiler warning rather than a compiler error.
Suggestion
This behavior was addressed in GitHub Issue #339. To eliminate this warning, you can download and compile an updated version of the source code for the Code Contracts tool from GitHub. Download information is found at the bottom of the page.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.1 |
Type | Runtime |
Affected APIs
Windows Communication Foundation (WCF)
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>
- If the binding is dynamically configured in source code, update the TcpTransportSecurity.SslProtocols property to use TLS 1.1 (SslProtocols.Tls11 or an earlier version of the protocol in the source code.
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 |
Affected APIs
Not detectable via API analysis.
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
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
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
CoerceIsSelectionBoxHighlighted
Details
Certain sequences of actions involving a System.Windows.Controls.ComboBox and its data source can result in a System.NullReferenceException.
Suggestion
If possible, upgrade to .NET Framework 4.6.2.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6 |
Type | Runtime |
Affected APIs
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 |
Affected APIs
Not detectable via API analysis.
Item-scrolling a flat list with items of different pixel-height
Details
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.
Suggestion
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:
- Install .NET Framework 4.6.2.
- Install hotfix HR 1605 for .NET Framework 4.6.1.
Name | Value |
---|---|
Scope | Minor |
Version | 4.6.1 |
Type | Runtime |
Affected APIs
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
ObjectDisposedException thrown by WPF spellchecker
Details
WPF applications occasionally crash during application shutdown with an System.ObjectDisposedException thrown by the spellchecker. This is fixed in .NET Framework 4.7 WPF by handling the exception gracefully, and thus ensuring that applications are no longer adversely affected. It should be noted that occasional first-chance exceptions would continue to be observed in applications running under a debugger.
Suggestion
Upgrade to .NET Framework 4.7
Name | Value |
---|---|
Scope | Edge |
Version | 4.6.1 |
Type | Runtime |
Affected APIs
Not detectable via API analysis.
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
WPF Spell Checking fails in unexpected ways
Details
This includes a number of WPF Spell Checker issues:
- WPF Spell Checker sometimes throws System.Runtime.InteropServices.COMException
- WPF Spell Checker fails with UnauthorizedAccessException when applications are launched using 'run as different user'
- WPF Spell Checker incorrectly identifies spelling errors in compound words like 'Hausnummer' in German.
Suggestion
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
XML
XML parsing changes
Name | Value |
---|---|
Scope | Minor |
Version | 4.5.2 |
Type | Runtime |
Details
For security reasons, the following changes were introduced into XML parsing APIS:
- XmlReaderSettings.MaxCharactersFromEntities is set to 10 million when XmlReaderSettings is initialized.
- XmlReaderSettings.XmlResolver is set to
null
by default.
Note
XmlReaderSettings is used by all XML parsers, so while this change helps the XmlReader case, it also affects other scenarios.
Suggestion
To revert to the previous behavior, you can set a value in the registry. Add a DWORD value named EnableLegacyXmlSettings
to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML
registry key, and set its value to 1
. You can also add the registry value in the HKEY_CURRENT_USER hive instead.
Affected APIs
In addition, any XML API that depends on XmlResolver, either directly or indirectly, is affected.
Feedback
Submit and view feedback for