Application Compatibility in the .NET Framework 4.5
This topic describes application compatibility issues between the .NET Framework 4 and the .NET Framework 4.5, including fixes and changes based on customer feedback. Most of these changes do not require any programming modifications in your applications. For those that may involve modifications, see the Impact column of the tables.
Note that the .NET Framework 4.5 is not supported on Windows XP.
This topic describes notable changes in the following areas:
This topic does not discuss types and members that have been declared obsolete in the .NET Framework 4.5. For a list of these, see What's Obsolete in the .NET Framework Class Library. For information about new features, see What's New in the .NET Framework 4.5.
The BlockingCollection.TryTakeFromAny(BlockingCollectionUTP, UTP) method no longer returns -1 or throws an exception. The BlockingCollection.TakeFromAny method no longer throws an exception if one of the collections is marked completed.
This change makes it possible to work with collections when one of the collections is either empty or completed, but the other collection still has items that can be retrieved.
Serialization and deserialization with the SoapFormatter class
Hashtable and similar ordered collection objects that are serialized under the .NET Framework 4.5 cannot be deserialized under the .NET Framework 4.
This change supports the use of cached tasks. For example, a method can return a cached task to represent an already completed operation instead of allocating a new task. This was impossible in previous .NET Framework versions, because any consumer of the task could dispose of it, which rendered it unusable.
Unobserved exceptions in Task operations
Because the Task class represents an asynchronous operation, it catches all non-severe exceptions that occur during asynchronous processing. In the .NET Framework 4.5, if an exception is not observed and your code never waits on the task, the exception will no longer propagate on the finalizer thread and crash the process during garbage collection.
This change enhances the reliability of applications that use the Task class to perform unobserved asynchronous processing. The previous behavior can be restored by providing an appropriate handler for the TaskScheduler.UnobservedTaskException event.
Task.WaitAll methods with time-out arguments
In the .NET Framework 4, these methods behaved inconsistently. When the time-out expired, if one or more tasks were completed or canceled before the method call, the method threw an AggregateException exception. When the time-out expired, if no tasks were completed or canceled before the method call, but one or more tasks entered these states after the method call, the method returned false.
In the .NET Framework 4.5, these method overloads now return false if not all tasks have completed before the time-out interval expired, and they throw an AggregateException exception only if all input tasks have completed.
This change makes the method's behavior consistent. However, it is possible (but unlikely) for application code to depend on time-out enabled Task.WaitAll overloads to throw an exception when at least one task has already faulted or has been canceled before the time-out has expired.
Support for type forwarding when multi-targeting
A new CodeDOM feature allows a compiler to compile against the targeted version of mscorlib.dll instead of the .NET Framework 4.5 version of mscorlib.dll.
This change prevents compiler warnings (and compilation failure in cases where warnings are treated as errors) when CodeDOM finds two definitions for types that have been type-forwarded. This change may have unintended side effects only if different versions of reference assemblies are mixed in a single location.
The enumerator throws an InvalidOperationException exception if an element in the collection is modified.
This change applies only to applications that target .NET Framework 4.5 and should have no negative impact. It safeguards data integrity and makes it more likely that race conditions will be identified.
Two changes to International Resource Identifier (IRI) parsing affect URIs in applications that target the .NET Framework 4.5:
URIs that contain non-NFC (normalization form C) normalized file names will not be form-C normalized. Application failure may result if IRI parsing uses non-normalized strings to access files that have normalized file names. This only affects applications that target the .NET Framework 4.5.
An invalid mailto: URL throws an exception in the Uri class constructor.
This only affects applications that are recompiled and that target the .NET Framework 4.5.
In applications that target the .NET Framework 4.5, trailing dots at the end of a path segment in an original URI string (for example, http://www.proseware.com/LLC./About.aspx) are preserved. (Note that path segments that consist exactly of one or two dots, such as http://www.proseware.com/.. or http://www.proseware.com/./default.htm, are removed, but path segments that have more than two consecutive dots (such as http://localhost/dir1/.../dir2) are preserved.
This change affects only applications that target the .NET Framework 4.5. Applications that rely on the trailing dots being removed may experience failure.
In applications that target the .NET Framework 4.5, queries in a file:// URI are allowed; the ? character is not escaped because it is interpreted as part of the path.
This change affects only applications that target the .NET Framework 4.5. Applications that rely on escaping the ? character may experience failure.
In applications that target the .NET Framework 4.5, Unicode control characters from U+0080 through U+009F are incorrectly encoded.
Ordinarily, Unicode control characters are not used in URIs.
The implementation of the IAsyncResult.CompletedSynchronously property must be correct for the resulting task to complete. That is, the property must return true if, and only if, the implementation completed synchronously. Previously, the property was not checked.
The resulting task will not complete if the implementation of the IAsyncResult.CompletedSynchronously property incorrectly returns true.
Ability to connect to a SQL Server database from managed code that runs under the .NET Framework 4.5.
The existing synchronous API code path was modified to add asynchronous support.
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to connect to SQL Server. For more information, see SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed on the Microsoft Support website.
Connections to SQL Server 1997 databases are no longer supported.
Applications running under the .NET Framework 4.5 cannot connect to SQL Server 1997 databases.
Connections to SQL Server databases using the Virtual Interface Adapter (VIA) protocol are no longer supported.
Applications running under the .NET Framework 4.5 cannot connect to SQL Server databases using VIA.
When inserting data into a column, SqlBulkCopy uses the encoding of the destination column rather than the default encoding for VARCHAR and CHAR types.
This change eliminates the possibility of data corruption caused by using the default encoding when the destination column does not use the default encoding. In rare cases, an existing application may throw a SqlException exception if the change in encoding produces data that is too big to fit into the destination column.
System.Data.SqlClient collation sequence
sql_variant data uses sql_variant collation rather than database collation.
This change addresses possible data corruption if the database collation differs from the sql_variant collation. Applications that rely on the corrupted data may experience failure.
Log files created by the ObjectContext.CreateDatabase method
When the CreateDatabase method is called either directly or by using Code First with the SqlClient provider and an AttachDBFilename value in the connection string, it creates a log file named filename_log.ldf instead of filename.ldf (where filename is the name of the file specified by the AttachDBFilename value).
This change improves debugging by providing a log file named according to SQL Server specifications. It should have no unexpected side effects.
Data Definition Language (DDL) APIs
The behavior of DDL APIs when AttachDBFilename is specified has changed as follows:
These changes make it easier to build tools and applications that use the DDL APIs. These changes can affect application compatibility in the following scenarios:
If the creation of database objects fails after an empty database is created, the method attempts to drop the database creation and propagates the original SqlException exception. If the attempt to drop the database fails, the method throws an InvalidOperationException exception.
This change prevents the creation of an empty, unusable database. Exception handling can change somewhat, because the successful removal of the database now propagates the original SqlException exception.
If T is an enumeration type, the method correctly returns data from the database. Previously, enumeration types were not supported, so the result was always cast to zero or converted to the enumeration type. Underlying types that are not supported by the Entity Framework, such as UInt16, UInt32, and UInt64; still return zero or are converted to the enumeration type with an underlying value of zero.
Support for enumerations is new in the Entity Framework in the .NET Framework 4.5. However, if developer code depends on the result to be zero, an application error could result, depending on the specific code.
When you run MSBuild at a command prompt, it will respect solution configuration files that disable builds of particular projects.
MSBuild behaves the same when called by Visual Studio and when run at a command prompt. You do not have to create separate solutions or remove projects from a solution to build a subset of projects in a solution.
The TreatAsLocalProperty property in MSBuild project files prevents specific properties, including the OutDir property, from being overridden at a global level.
Overrides to the OutDir property may cause a potential break if OutDir is a global property that is overridden after the MS.Common.Targets file is imported.
Windows error reporting: Watson buckets
Managed crashes are grouped into categories based on a number of criteria, one of which was the assembly version. In the .NET Framework 4.5, the file version is used instead of the assembly version.
Because the assembly version changes only between major releases, using the file version instead of the assembly version as a category makes it possible to determine the specific version of an assembly that has been involved in a managed crash.
ASP.NET IIS registration tool (aspnet_regiis.exe)
On Windows 8, the –i and –u options to install and uninstall ASP.NET are not supported.
To install or uninstall ASP.NET 4.5 with IIS 8, use the Turn Windows Features On/Off dialog box, the Server Management tool, or the dism.exe command-line tool.
This change eliminates an extraneous trip to the database, prevents the values of controls from being reset, and produces behavior that is consistent with other data controls, such as SqlDataSource and ObjectDataSource. This change produces different behavior in the unlikely event that applications rely on invoking data binding in the Page.LoadComplete event.
By default, decoding methods no longer decode an invalid input sequence into an invalid UTF-16 string. Instead, they return the original input.
The change in decoder output should matter only if you store binary data instead of UTF-16 data in strings. To explicitly control this behavior, set the aspnet:AllowRelaxedUnicodeDecoding attribute of the <appSettings> element to true to enable legacy behavior or to false to enable the current behavior.
For applications that target the .NET Framework 4.5, characters that are outside the Basic Multilingual Plane (BMP) round-trip correctly when they are passed to the WebUtility.HtmlDecode method.
This change should have no effect on current applications. To restore the original behavior, set the targetFramework attribute of the <httpRuntime> element to a string other than "4.5". You can also set the unicodeEncodingConformance and unicodeDecodingConformance attributes of the <webUtility> configuration element to control this behavior independently of the targeted version of the .NET Framework.
UTF-7 encoding is prohibited.
Data for applications that depend on incoming UTF-7 data will not decode properly in some cases. This should be rare, but you can restore legacy behavior by using the aspnet:AllowUtf7RequestContentEncoding attribute of the <appSettings> element.
These methods are now obsolete.
Managed browser hosting controls from the .NET Framework 1.1 and 2.0
Hosting these controls is blocked in Internet Explorer.
Internet Explorer will fail to launch an application that uses managed browser hosting controls. The previous behavior can be restored by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/MICROSOFT/.NETFramework to 1 for x86 systems and for 32-bit processes on x64 systems, and by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/Wow6432Node/.NETFramework to 1 for 64-bit processes on x64 systems.
Messages in WCF web services hosted in Internet Information Services (IIS) or ASP.NET Development Server that exceed maxRequestLength (in ASP.NET) or maxReceivedMessageSize (in WCF)
The HTTP status code has changed from 400 (Bad Request) to 413 (Request Entity Too Large), and messages that exceed either the maxRequestLength or the maxReceivedMessageSize setting throw a ProtocolException exception. This includes cases in which the transfer mode is Streamed.
This change facilitates debugging in cases where the message length exceeds the limits allowed by ASP.NET or WCF.
You must modify any code that performs processing based on an HTTP 400 status code.
The WebServiceHost object no longer adds a default endpoint if an explicit endpoint has been added by application code.
If a client application tries to connect to an endpoint that is no longer added by default, an HTTP error results.
The constructor has been deprecated.
The constructor does not work on 64-bit systems. Use the EncoderParameter.#ctor(Encoder, Int32, EncoderParameterValueType, IntPtr) constructor instead.
This change should have no negative impact. However, you can explicitly set the UndoLimit property after instantiating the control.
This change should have no impact on existing applications. The default is PageRangeSelection.AllPages for existing members that use this enumeration.
DataTemplate elements now appear in the control view of the UI Automation (UIA) tree.
This change improves accessibility. However, it affects test tools that rely on the previous structure of the UIA tree to locate neighboring elements.
Synchronization of the TextBox.Text property and the property to which it is bound
In some cases, the TextBox.Text property reflects a previous value of the databound property value if the property is modified during a databinding write operation.
This should have no negative impact. However, you can restore the previous behavior by setting the FrameworkCompatibilityPreferences.KeepTextBoxDisplaySynchronizedWithTextProperty property to false.
When a TextBox control is inactive, selected text inside the box displays in a different color than when the text box is active.
You can restore the previous behavior by setting the FrameworkCompatibilityPreferences.AreInactiveSelectionHighlightBrushKeysSupported property to false.
The assembly is marked with the AllowPartiallyTrustedCallersAttribute attribute.
WF 3.0 types and members
The types and members of WF 3.0 are now marked as obsolete.
Trying to compile source code that uses WF 3.0 types or members generates a compiler error. You should use the WF 4 types and members in the System.Activities namespaces.
The DragDropHelper class includes new methods that support drag-and-drop operations with multiple objects. Existing drag-and-drop methods that support dragging a single object are obsolete. (For more information, see What's Obsolete in the .NET Framework Class Library.)
Although the old methods have been deprecated, they continue to be supported by both the compiler and the common language runtime. However, the new methods offer greater functionality. The recommended replacements for some of the existing methods are as follows:
Overload resolution of calls to the Dispatcher.Invoke method
The .NET Framework 4.5 adds new overloads that include a parameter of type Action. When existing code is recompiled, compilers may resolve calls to Dispatcher.Invoke methods that have a Delegate parameter as calls to Dispatcher.Invoke methods with an Action parameter.
The associated ValueSerializer object will convert a DateTime or DateTimeOffset object whose Second and Millisecond components are non-zero and (for a DateTime value) whose DateTime.Kind property is not Unspecified to property element syntax instead of a string.
If the LoadOptions.SetLineInfo value is passed to the Load method and a validation error occurs, the XmlSchemaException.LineNumber and XmlSchemaException.LinePosition properties now contain line information.
Forward compatibility mode for the XslCompiledTransform class
In the .NET Framework 4, XSLT 1.0 forward compatibility had the following issues:
In the .NET Framework 4.5, these issues have been fixed, and XSLT 1.0 forward compatibility mode works properly.
XSLT 1.0 forward compatibility mode now works as previously.
Exception messages when an XSLT file is too complex
In the .NET Framework 4.5, the text of the error message when an XSLT file is too complex is "The style sheet is too complex." In previous versions, the error message was "XSLT compile error."
Application code that depends on the text of the error message will no longer work. However, the exception types remain the same, so this change should have no real impact.
XML schema validation for xsd:anyURI
In the .NET Framework 4.5, XML schema validation is more strict. If you use xsd:anyURI to validate a URI such as a mailto protocol, validation fails if there are spaces in the URI. In previous versions of the .NET Framework, validation succeeded.
The change affects only applications that target the .NET Framework 4.5.