While attending PDC last week I attended a session on what is coming with the CLR in .NET 4.0. I know there are plenty of developers who don't worry about the CLR, but I thought it would be nice to give a quick rundown of what was shared.
CLR 4.0 will be a side by side release instead of built on top of CLR 2.0 as .NET 3.0 and .NET 3.5 were. You will be able to use components that are 2.0 and 4.0 based in the same process without compatibility problems.
With the addition of some new F# and Python data types like BigInteger and Tuples to the Base Class Libraries, all languages benefit. So you can consume these in C# of whatever .NET language you use. Tuples sound interesting, essentially they are a construct used to create a class on the fly. So you can technically you could use a tuple to eliminate your use of out parameters, need more research on this though.
CLR 4.0 will provide some parallel extensions to incorporate in your code. Parallel execution introduces a lot of questions though so curious to see this in action. One example shown other than Parallel.For() and Parallel.ForEach() was a LINQ statement that leveraged a .AsParallel() extension method, see below.
var rslt = from item in shows.AsParallel()
where item.Description.Contains(keywork) &&
item.Year > startYear
orderby item.StartTime ascending
select item;
Garbage Collection has gotten some attention as well to help reduce latency. For those who are using .NET in a load balancing situation there is a new feature allowing you to capture a notification that a Gen2 collection needs to take place. So when you catch the notification, you can redirect traffic while you perform the GC.Collect. This solution would require you perform the GC.Collect which is not normally recommended, but necessary in this case. But wait, there's more. There is a new Background Collection Feature (this is what they called it) that will allow Gen2 to collect at the same time as Gen0 or Gen1. So you will see less pausing over the lifetime of your application.
Another interesting proposition that I can see a few people using is the ability to attach and detach performance and memory profilers to a live .NET process running on the server. From what I gathered this is done via an API that they are going to encourage third party profilers to leverage.
One of the last items discussed revolved around Corrupted State Exceptions. For those folks that catch (Exception e) this is for you. When an Access violation or illegal instruction is hit, you will no longer catch those exceptions. The new policy is to keep these from you and keep them out of your hands. Don't worry though, if you feel you must there will still be a way to catch them using either an attribute or set a process wide compatibility switch.
All of these are interesting features of the new CLR. I look forward to seeing more information on several of these items as things move forward.
