Application Compatibility in the .NET Framework 4.5 Beta

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.

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 Beta, 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 Beta, 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 Beta 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.

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

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

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

MSBuild

When you run MSBuild from the command line, it will respect solution configuration files that disable builds of particular projects.

MSBuild behaves the same when called by Visual Studio and when run from the command line. You do not have to create separate solutions or remove projects from a solution to build a subset of projects in a solution.

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 Beta, 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.

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.

System.Web.Hosting.IISAPIRuntime interface

This interface has changed from public to internal.

There should be no impact; this interface was documented as being for internal use only.

System.Web.Hosting.ISAPIRuntime interface

This interface has changed from public to internal.

There should be no impact; this interface was documented as being for internal use only.

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.

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.

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

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 System.Activities.Presentation.DragDropHelper.DoDragMove(System.Collections.Generic.IEnumerable{System.Activities.Presentation.WorkflowViewElement},System.Windows.Point) instead of DoDragMove.

• Use GetCompositeView instead of GetCompositeView.

• Use GetDraggedModelItems instead of GetDraggedModelItem.

• Use GetDroppedObjects instead of GetDroppedObject.

Overload resolution of calls to the Dispatcher.Invoke method

The .NET Framework 4.5 Beta 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.

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.

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 Beta, these issues have been fixed, and XSLT 1.0 forward compatibility mode works properly.

XSLT 1.0 forward compatibility mode now works as previously.