Runtime Changes for Migration from .NET Framework 4.5 to 4.5.2
- (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 to 4.5.2, 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 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
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, an alternate serializer like the System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serializer 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.
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
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.
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
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 |
Affected APIs
Not detectable via API analysis.
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)
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 |
Affected APIs
Not detectable via API analysis.
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)
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
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.
Serialization
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:
- Upgrade the serializing computer to use the .NET Framework 4.5.1, as well.
- Use System.Runtime.Serialization.DataContractSerializer instead of System.Runtime.Serialization.NetDataContractSerializer as this does not expect the exact same CLR types at both serializing and deserializing ends.
- Use System.Collections.Generic.Dictionary<TKey,TValue> instead of System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> since it does not exhibit this particular 4.5->4.5.1 break.
| Name | Value |
|---|---|
| Scope | Minor |
| Version | 4.5.1 |
| Type | Runtime |
Affected APIs
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 |
Affected APIs
Not detectable via API analysis.
Windows Presentation Foundation (WPF)
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
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.
Scrolling a WPF TreeView or grouped ListBox in a VirtualizingStackPanel can cause the application to stop responding
Details
In the .NET Framework v4.5, scrolling a WPF System.Windows.Controls.TreeView in a virtualized stack panel can cause the application to stop responding 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
WPF spawns a wisptis.exe process which can freeze the mouse
Details
An issue was introduced in 4.5.2 that causes wisptis.exe to be spawned that can freeze mouse input.
Suggestion
A fix for this issue is available in a servicing release of the .NET Framework 4.5.2 (hotfix rollup 3026376), or by upgrading to the .NET Framework 4.6
| Name | Value |
|---|---|
| Scope | Major |
| Version | 4.5.2 |
| Type | Runtime |
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
nullby 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.
Povratne informacije
Pošalјite i prikažite povratne informacije za