Application Compatibility in the .NET Framework 4.5

.NET Framework (current version)

This topic describes application compatibility issues between the .NET Framework 4 and 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.


For compatibility issues between the .NET Framework 4.5 and 4.5.1, see Application Compatibility in the .NET Framework 4.5.1.

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.

In addition to the following application compatibility issues, see the Serialization section for serialization-related issues.




BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T) and BlockingCollection<T>.TakeFromAny methods

The BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T) method no longer returns -1 or throws an exception. The BlockingCollection<T>.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.


If an assembly of compiled regular expressions is built with the .NET Framework 4.5 but targets the .NET Framework 4, attempting to use one of the regular expressions in that assembly on a system with .NET Framework 4 installed throws an exception.

To work around this problem, you can do either of the following:

Build the assembly that contains the regular expressions with the .NET Framework 4.

Use an interpreted regular expression.

System.Threading.Tasks.Task disposal

Except for Task.IAsyncResult.AsyncWaitHandle, System.Threading.Tasks.Task methods no longer throw an ObjectDisposedException exception after the object is disposed.

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 System.Threading.Tasks.Task operations

Because the System.Threading.Tasks.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 any tasks are still running when the time-out interval expires, and they throw an AggregateException exception only if an input task was cancelled (regardless of whether it was cancelled before or after the method call) and no other tasks are still running.

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. In that case, the Task.IsCanceled property can be used for the same purpose.

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:

<iriParsing> is enabled by default and cannot be turned off. Previously, it was disabled by default.

Unicode normalization form C (NFC) will no longer be performed on non-host portions of URIs. Previously, NFC was performed on the entire URI when <iriParsing> was enabled.

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, are preserved. (Note that path segments that consist exactly of one or two dots, such as or, 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.

Uri.EscapeDataString, Uri.EscapeUriString, and Uri.UnescapeDataString

The list of reserved and unreserved characters now supports RFC 3986.

Specific changes: 

EscapeDataString escapes reserved characters based on RFC 3986.

EscapeUriString does not escape reserved characters.

UnescapeDataString does not throw an exception if it encounters an invalid escape sequence.

Unreserved escaped characters are un-escaped.


Beginning with the .NET Framework 4.5, strings are always considered well-formed in accordance with RFC 3986 and RFC 3987. In previous versions of the .NET Framework, a string is considered well-formed in accordance with RFC 3986 and RFC 3987 only if URI parsing and IDN parsing are enabled.

For apps that target the .NET Framework 4.5 or later versions, this method returns false for some URIs that are considered well-formed by apps that target earlier versions of the .NET Framework. For example, a relative URI that includes a colon in its first segment (such as "2013.05.29_14:33:41") is no longer considered well-formed.

Note that this change only affects apps that target the .NET Framework 4.5 or later versions.


The TaskFactory.FromAsync may now access the IAsyncResult.CompletedSynchronously property. Incorrect implementations of IAsyncResult.CompletedSynchronously may now result in undefined behavior in TaskFactory.FromAsync method calls.

The resulting task will not complete if the implementation if 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.

System.Data.SqlClient.SqlConnection type

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.

System.Data.SqlClient.SqlConnection type

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.

System.Data.SqlClient.SqlBulkCopy type

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:

Connection strings need not specify an Initial Catalog value. Previously, both AttatchDBFilename and Initial Catalog were required.

If both AttatchDBFilename and Initial Catalog are specified and the given MDF file exists, the ObjectContext.DatabaseExists method returns true. Previously, it returned false.

If both AttatchDBFilename and Initial Catalog are specified and the given MDF file exists, calling the ObjectContext.DeleteDatabase method deletes the files.

If ObjectContext.DeleteDatabase is called when the connection string specifies an AttachDBFilename value with an MDF that doesn't exist and an Initial Catalog that doesn't exist, the method throws an InvalidOperationException exception. Previously, it threw a SqlException exception.

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:

The user writes code that executes a DROP DATABASE command directly instead of calling ObjectContext.DeleteDatabase if ObjectContext.DatabaseExists returns true. This breaks existing code If the database is not attached but the MDF file exists.

The user writes code that expects the ObjectContext.DeleteDatabase method to throw a SqlException exception rather than an InvalidOperationException exception when the Initial Catalog and MDF file don't exist.

ObjectContext.CreateDatabase and DbProviderServices.CreateDatabase methods

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.

ObjectContext.Translate<TEntity> and ObjectContext.ExecuteStoreQuery<TElement> methods

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.




Enumerable.Empty<TResult> method

The method returns a cached internal instance instead of returning a new IEnumerable<T> type.

This change results in a performance improvement. However, code that depends on getting two unique empty types from multiple calls to Enumerable.Empty<TResult> will fail.




Types and members of the System.Net.PeerToPeer.Collaboration namespace

The types and members are not supported on Windows 8. Attempting to call them throws a PlatformNotSupportedException exception.

Applications can no longer use these types and members on Windows 8.

Serialization and deserialization of MailMessage objects.

In the .NET Framework 4.5, mail messages can include non-ASCII characters. In the .NET Framework 4, only ASCII characters are supported.

 MailMessage objects that contain non-ASCII characters and that are serialized under the .NET Framework 4.5 cannot be deserialized under the .NET Framework 4.





This property exposes the stream of a print job and allows the user to send raw data to the underlying operating system printing components by writing to this stream.

Starting with the .NET Framework 4.5 on Windows 8 and later versions of the Windows operating system, data written to this stream must be in XPS format as a package stream.

To output print content, you can do either of the following:

Use the XpsDocumentWriter class to output print content. This is the recommended alternative.

Ensure the data sent to the stream returned by the PrintSystemJobInfo.JobStream property is in XPS format as a package stream.




Serialization with the XmlSerializer class

In WCF 4.5, the XmlSerializer class was optimized to remove its dependency on the C# compiler. This change provides significant performance gains for cold startup scenarios.

This change may cause problems in XML serialization code that was compiled in WCF 4 but is running against WCF 4.5. If you encounter any problems running your existing XML serialization code in WCF 4.5, use the following configuration element to revert to the XmlSerializer behavior in WCF 4:

<configuration> <system.xml.serialization> <xmlSerializer useLegacySerializerGeneration="true"/> </system.xml.serialization> </configuration>

Serialization and deserialization with the System.Runtime.Serialization.Formatters.Soap.SoapFormatter class

Serialization using SoapFormatter can encode an object’s internal state, which is not guaranteed to be the same between versions of the .NET Framework.  Where there are differences, content serialized in one version of the .NET Framework may fail to deserialize on others.

The SoapFormatter class does not guarantee cross-version compatibility. Use the System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and System.Runtime.Serialization.NetDataContractSerializer classes instead.





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.


Data from projects in the Microsoft.Build.Evaluation.ProjectCollection collection is not automatically reclaimed by the garbage collector.

If you explicitly load projects into the ProjectCollection collection, you should call the UnloadProject(Project) method for each member of the collection.




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.

System.Web.UI.WebControls.EntityDataSource control

The Page.LoadComplete event no longer causes the System.Web.UI.WebControls.EntityDataSource control to invoke data binding for changes to create/update/delete parameters.

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.

WebUtility.HtmlDecode, WebUtility.UrlDecode, and System.Web.Helpers.Json.Decode methods

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.

WebUtility.HtmlEncode method

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.

HttpRequest.ContentEncoding property

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.


Starting with the .NET Framework 4.5, the method escapes the ampersand (&) character.

If your app depends on the previous behavior of this method, you can add an aspnet:JavaScriptDoNotEncodeAmpersand setting to the ASP.NET appSettings element in your configuration file.

MachineKey.Encode and MachineKey.Decode methods

These methods are now obsolete.

Compilation of code that calls these methods produces a compiler warning. The recommended alternatives are MachineKey.Protect and MachineKey.Unprotect.




Apps published with ClickOnce that use a SHA-256 code-signing certificate.

The executable is signed with SHA256. Previously, it was signed with SHA1 regardless of whether the code-signing certificate was SHA-1 or SHA-256. This applies to:

All applications built with Visual Studio 2012 or later.

Applications built with Visual Studio 2010 or earlier on systems with the .NET Framework 4.5 present.

In addition, if the .NET Framework 4.5 or later is present, the ClickOnce manifest is also signed with SHA-256 for SHA-256 certificates regardless of the .NET Framework version against which it was compiled.

The change in signing the ClickOnce executable affects only Windows Server 2003 systems; they require that KB 938397 be installed.

The change in signing the manifest with SHA-256 even when an app targets the .NET Framework 4 or earlier versions introduces a runtime dependency on the .NET Framework 4.5 or a later version. This issue is resolved in Visual Studio 2013 Update 3 and in .NET Framework 4.6. For the .NET Framework 4.6 resolution, see Runtime Changes in the .NET Framework 4.6.




System.ComponentModel.Composition.Primitives.ComposablePartCatalog and its derived classes

Starting with the .NET Framework 4.5, MEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer (XmlSerializer object).

Trying to serialize a MEF catalog throws an exception.




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/Microsoft/.NETFramework to 1 for 64-bit processes on x64 systems.

In addition to the following application compatibility issues, see the Serialization section for serialization-related issues.




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.

Replace in OData URLs

The Replace method in OData URLs is disabled by default.

When OData Replace is disabled (now by default), the user request will throw an exception and the request will fail.


The System.ServiceModel.Web.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 CheckForOverflowUnderflow property for the assembly is set to true.

Previously when overflows occurred, the result would be silently truncated. Now an OverflowException exception is thrown.

EncoderParameter.EncoderParameter(Encoder, Int32, Int32, Int32) constructor

The constructor has been deprecated.

The constructor does not work on 64-bit systems. Use the EncoderParameter.EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr) constructor instead.

In addition to the following application compatibility issues, see the Serialization section for serialization-related issues.




TextBoxBase.UndoLimit property

The default limit to the maximum number of undo operations for the TextBox and RichTextBox classes has changed from -1 (no limit) to 100.

This change should have no negative impact. However, you can explicitly set the UndoLimit property after instantiating the control.

System.Windows.Controls.PageRangeSelection enumeration

The CurrentPage and SelectedPages members have been added to the enumeration.

This change should have no impact on existing applications. The default is PageRangeSelection.AllPages for existing members that use this enumeration.

DataTemplate elements

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.

System.Windows.Controls.TextBox property

When a System.Windows.Controls.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.


If a control derived from MultiSelector with CanSelectMultipleItems set to true has duplicates in its MultiSelector.SelectedItems collection, the duplicated items appear more than once. Removing these items from the data source (for example, by calling Items.Clear) fails to remove them from the MultiSelector.SelectedItems collection; only the first instance is removed.

Subsequent use of the MultiSelector.SelectedItems collection, such as a call to SelectedItems.Clear, can encounter problems, such as an ArgumentException, because the MultiSelector.SelectedItems collection contains items that are no longer in the data source.

This issue has been addressed in the .NET Framework 4.6.2. If a MultiSelector.SelectedItems collection has duplicate items, you remove them from the data source, and you wish to continue working with the MultiSelector.SelectedItems collection, upgrade to the .NET Framework 4.6.2.


In the .NET Framework 4, the method returns a reference to the current instance. In the .NET Framework 4.5, it returns a new instance.

Code that assumes equal references indicate that the executing thread is in the correct context will now execute correctly. However, because of the change, code that calls DispatcherSynchronizationContext.CreateCopy should be tested.

Monitoring WM_POWERBROADCAST messages by using a handler added by calling the HwndSource.AddHook method.

A window must explicitly register for WM_POWERBROADCAST notifications by passing its handle to the RegisterPowerSettingNotification function. Through the .NET Framework 4, WPF automatically did this for all windows. Starting with the .NET Framework 4.5, WPF automatically registers one special window, but does not automatically register most app windows.

Code that handles WM_POWERBROADCAST notifications does not execute.

To continue to receive WM_POWERBROADCAST notifications, call the RegisterPowerSettingNotification function to register a WPF window (typically the main application window) for WM_POWERBROADCAST notifications. In WPF apps that you develop with C#, this also requires that you select the Allow unsafe code box on the project properties Build tab.

In addition, if you are registering a window that does not persist until application shutdown, you should unregister it by calling the UnregisterPowerSettingNotification function and passing it the HPOWERNOTIFY handle returned by the call to the RegisterPowerSettingNotification function.




System.Activities.dll security

The assembly is marked with the AllowPartiallyTrustedCallersAttribute attribute.

Derived classes cannot be marked with the SecurityCriticalAttribute. Previously, derived types had to be marked with the SecurityCriticalAttribute. However, this change should have no real impact.

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.

System.Activities.Presentation.DragDropHelper class

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:

Use DragDropHelper.DoDragMove(WorkflowViewElement, Point) instead of DragDropHelper.DoDragMove(WorkflowViewElement, Point).

Use GetCompositeView(WorkflowViewElement) instead of GetCompositeView(DragEventArgs).

Use GetDraggedModelItems(DragEventArgs) instead of GetDraggedModelItem(DragEventArgs).

Use GetDroppedObjects(DependencyObject, DragEventArgs, EditingContext) instead of GetDroppedObject(DependencyObject, DragEventArgs, EditingContext).

Overload resolution of calls to the Dispatcher.Invoke method

The .NET Framework 4.5 adds new overloads that include a parameter of type System.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 System.Action parameter.

If a call to a Dispatcher.Invoke overload with a Delegate parameter is resolved as a call to a Dispatcher.Invoke overload with an System.Action parameter, the following differences in behavior may occur:

If an exception occurs, the Dispatcher.UnhandledExceptionFilter and Dispatcher.UnhandledException events are not raised. Instead, exceptions are handled by the UnobservedTaskException event.

Calls to some members, such as DispatcherOperation.Result, block until the operation has completed.

System.Activities.Expressions.Literal<T> class

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.

This change allows DateTime and DateTimeOffset values to be round-tripped. Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.




XDocument.Validate method

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.

Exception-handling code that depends on the values of the XmlSchemaException.LineNumber and XmlSchemaException.LinePosition properties will no longer work.

Loading XML files with System.Xml.XmlTextReader

DTD entity expansion is limited to 10,000,000 characters.

Loading XML files without DTD entity expansion or with limited DTD entity expansion is unaffected. Files with DTD entities that expand to more than 10,000,000 characters fail to load, and now throw an exception.

Forward compatibility mode for the System.Xml.Xsl.XslCompiledTransform class

In the .NET Framework 4, XSLT 1.0 forward compatibility had the following issues:

Loading a style sheet failed if its version was set to 2.0 and the parser encountered an unrecognized XSLT 1.0 construct.

The xsl:sort construct failed to sort data if the style sheet version was set to 1.1.

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.