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.
System.Net.PeerToPeer.Collaboration
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.
WCF
When the maxRequestLength or maxReceivedMessageSize quota is exceeded the HTTP status code has changed from 400 (Bad Request) to 413 (Request Entity Too Large).
WPF
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.
XML/XSLT
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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/dotnet-spa-templates-proxy/en/smallimage/ASP-NET-SPA-templates-proxy-changes-small-1683016303172.jpg)
/presentations/net-apps-cloud/en/smallimage/infoq-live-logo-small-1683100880551.jpg){kind=logo}
/articles/asp-dotnet-minimal-apis/en/smallimage/logo-1678972581766.jpg){kind=logo}
/articles/functional-dotnet-development/en/smallimage/Fsharp-vs-Csharp-is-one-more-functional-than-the-other-small-1676023056578.jpg)
/articles/dotnet-grpc-json-transcoding/en/smallimage/logo-1674822319367.jpg){kind=logo}
/articles/Dotnet-Seven-MSMQ-Alternatives/en/smallimage/logo-1670585778128.jpg){kind=logo}
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/software-delivery-performance-indicators/en/smallimage/software-delivery-performance-indicators-at-different-granularities-small-1684312207072.jpg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/presentations/dark-energy-matter-microservices/en/smallimage/chris-richardson-small-1684240727275.jpg)
/presentations/techno-solutionism-ethics/en/smallimage/katharine-jarmul-small-1684239823523.jpg)
Community comments
Reflection
by Rob Eisenberg,
Re: Reflection
by Andrey Kuznetsov,
Re: Reflection
by Jonathan Allen,
Re: Reflection
by Rob Eisenberg,
Re: Reflection
by Andrey Kuznetsov,
Re: Reflection
by Stefan Dobrev,
Why
by Mike Gale,
Reflection
by Rob Eisenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
One of the biggest changes I know about in 4.5 is that the entire reflection model has been overhauled. Almost all code written against System.Type will be broken.
Re: Reflection
by Andrey Kuznetsov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Wasn't it just about "Metro" profile?
channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-930C
As I understand this sessions, that was true only for WinRT/Metro.
Re: Reflection
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
That is correct. Though it surely shares some components, the ".NET for Windows 8" profile is separate from the ".NET Framework 4.5" profile. It is best to think of it the same way you think of .NET 4.0 vs Silverlight.
Why
by Mike Gale,
Your message is awaiting moderation. Thank you for participating in the discussion.
It would be useful is we got the inside details of why this decision was made.
It seems to fly in the face of why such detailed version number are used. It just looks plain wrong, by definition.
Anyone know who made this decision and what their thinking was?
Have the decision makers written programs recently?
Re: Reflection
by Rob Eisenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
Actually, I was in the BUILD session with Krzysztof Cwalina and I specifically asked if the System.Type changes were for WinRT only or for .NET 4.5. He said they were changes in .NET 4.5.
Re: Reflection
by Andrey Kuznetsov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sorry Rob, but I still think that Krzystof has Metro profile of .NET 4.5 in thoughts.
And of course it wasn't change in WinRT, which is native library basically, and doesn't have System.Type in it.
If that's not the case, it would by kind of strange 'in-place update' and 'high compatibility target'
Re: Reflection
by Stefan Dobrev,
Your message is awaiting moderation. Thank you for participating in the discussion.
Let me shed more light in here.
First of all System.Type is not going away from the .NET Framework. The whole framework depends on this type so it will never go away. What they did in .NET 4.5 is to introduce a new type called TypeInfo that will contain only the reflection part the Type class (this is similar to the native IInspectable interface in WinRT). They also introduce handy extension methods on top of System.Type one of them being GetTypeInfo().
Now let's talk what is a .NET framework profile. It's is collection of APIs specifically designed for a target domain where the profile will be used. Each profile represents a set of reference assemblies (there is IL only for signatures and no actual implementation) that are used to drive the development experience. At runtime via some attribute magic the correct runtime types are resoled and everything is working as expected. This concept was introduced in Portable Library Tools and will be extended going forward as we see .NET used on many places - XBox, Silverlight, Phone, Metro, etc. You can watch this Channel9 video for more information.
Having laid out the ground let's look at what is .NET Profile For Metro Applications aka .NET 4.5 Core Profile. It is a framework profile that contains subset of .NET API specifically designed for Metro apps. You can think of it as what will .NET Core Framework look like as if Microsoft is designing it right now having learned from the past. Regarding the Type class in this profile they have hidden its reflection members, because you should access them via TypeInfo class and you can get one of those via GetTypeInfo() extension method.
-sdobrev