Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Breaking Changes Planned for .NET 4.5

Breaking Changes Planned for .NET 4.5

This item in japanese

The actual version number for .NET 4.5 assemblies is 4.0.30319. If that looks familiar it is because that is also the version number for .NET 4.0 assemblies. Much to the chagrin of developers, Microsoft will be updating core assemblies “in-place”. Aside from making much harder to determine which version of .NET the user actually has installed, it creates numerous pitfalls for developers targeting .NET 4.0 with machines that have 4.5 installed.

While Visual Studio is quite capable of keeping developers from accidentally using .NET 3.0 or 3.5 assemblies in projects targeting .NET 2.0 the same cannot be said for individual methods. Within the IDE there is no warning that method in a common library such as mscorlib.dll or System.dll didn’t exist in the older version. Unless a static analysis tool is used to programmatically check for such mistakes, the error will probably not be detected until the code fails at runtime. A good example of this is EventWaitHandle.WaitOne, which has overloads that were added via a service pack that shipped with .NET 3.5.

While this is still a theoretical problem at this time, there are also several breaking changes in .NET 4.5 that will need to be accounted for.

Unhandled, unobserved exceptions

In .NET 2.0 the semantics for unhandled exceptions changed. Prior to this version exceptions on a non-UI thread would simply be discarded and the associated thread terminated. As of .NET 2.0, unhandled exceptions would cause the entire application to crash. While this greatly reduced the possibility of data corruption and undetected errors, it also meant that all calls made on back-ground threads were handled a top-level exception handler.

When the Task Parallel Library was introduced it followed this model. If a Task is faulted, its Exception property must be read before the Task is garbage collected. Failing to do so will cause the finalizer to terminate the application on the grounds that it had an unhandled exception.

In .NET 4.5 the rule for Tasks will change to be like the pre-2.0 rule for threads. While a global event will be raised for logging purposes, faulted Tasks will no longer crash the application.


The namespace System.Net.PeerToPeer.Collaboration is not available and no explanation was given why.

These libraries were only available on non-server versions of Windows Vista and Windows 7 and are an extension to the Windows Peer-to-Peer Infrastructure. Being a rarely used subset of a rarely used technology, there is very little information on this namespace and it is unlikely to affect more than a handful of developers.


When the maxRequestLength or maxReceivedMessageSize quota is exceeded the HTTP status code has changed from 400 (Bad Request) to 413 (Request Entity Too Large).


The default value of TextBoxBase.UndoLimit has been changed from -1 (unlimited) to 100. No explanation was given, but presumably this offers a performance advantage over storing an indefinite number of prior versions of the text box contents.


Validation errors throw by XDocument will now include the line number and position if LoadOptions.SetLineInfo was passed to the Load method.

Forward compatibility mode for the System.Xml.Xsl.XslCompiledTransform class has been fixed.

Rate this Article