.NET 4.0 is the first release of .NET since 2.0 that evolves .NET for every programmer. .NET 3.0 was largely LINQ and .NET 3.5 was largely new namespaces (like WCF, WWF, etc.)
.NET 4.0 evolves the programming and design for any programmer. It offers framework support for parallel processing (PFX will be released), Code Contracts (now DbC is a reality at the framework level, and opens the possibility of it being a reality at the language level post 2010), variance changes (co- and contra-variance on generics interfaces and delegates is now a reality).
Parallel Processing
Moore's law has changed from single processors doubling in speed every 18 months to doubling in processing power through increased core count every 18 months. This means for applications to make use of processing power increases they must increasingly make use of parallel processing and multi-threading. The PFX makes this more a reality by providing a framework by which application designers can more easily write code to support multi-core processors and multi-processor computers.
With PFX writing a loop to make use of multiple processors (while still supporting single processors) will be as easy as:
uint[] numbers = new uint[] {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20};
Parallel.ForEach(numbers, delegate(uint number) { Trace.WriteLine(CalculateFibonacci(number)); });
Code Contracts
Design by contract is a form of writing software with verifiable interface specifications. These specifications can be used at compile time to find code that breaks the contract and not require checking of the contract at run-time. For example:
[ContractInvariantMethod]
public int Calculate()
{
int result = 0;
foreach (int value in values)
{
this.operation(ref result, value);
}
return result;
}
If anything modifies the current class within the Calculate method, an exception will be thrown at run-time. Compilers will eventually be able to perform rudimentary checks at compile-time to ensure these contracts are abided by. For example:
[ContractInvariantMethod]
public int Calculate()
{
int result = 0;
foreach (int value in values)
{
this.operation(ref result, value);
}
this.date = DateTime.Now;
return result;
}
...may eventually cause a compile error on the assignment to this.date. The person designing this type intended this method to be invariant, meaning it doesn't change the state of the object to which it belongs. This design attribute can now be guaranteed.
Being able to include more design aspects in code and code definitions is a great step forward in not only writing intention-revealing code but in the ability to write more reliable code.
Variance changes
C# has always had intuitive variance when it came to arrays. For example, the following is valid code:
Shape[] shapes = new Triangle[10];
Given:
class Shape {
//...
}
class Triangle : Shape {
//...
}
Generics variance was a different storey. Prior to Visual C# 2010, this following is a compile error:
Func<Triangle> triangle = () => new Triangle();
Func<Shape> shape = triangle;
...despite Triangle being a type of shape (or otherwise known as "bigger" than Shape). This is known as invariant. In Visual C# 2010 you can now create delegates (as well as types and methods) that are no longer invariant. For example, a Func delegate could be created that is covariant:
delegate T Func<out T>();
(not the new use of the out keword) ...which could make our previous code:
Func<Triangle> triangle = () => new Triangle();
Func<Shape> shape = triangle;
...compiler without error.
The same can be done for contravariance with the the new use of the in keyword:
delegate T Action<in T>(T value);
For more details on generics variance, please see Eric Lippert's series on generics variance: http://blogs.msdn.com/ericlippert/archive/tags/Covariance+and+Contravariance/default.aspx
Other
Another notable improvement is side-by-side (SxS) support for multiple versions of .NET. This allows hosting of more than one version of the CLR within a single process. This makes writing shell extensions, for example, in C# a reality in .NET 4.0. You shouldn't need to target .NET 4.0, but as long as .NET 4.0 is installed you should be able to write shell extensions in a current version of .NET (like .NET 2.0) and it will be supported. Prior to .NET 4.0, a process could only have one version of the CLR loaded into a process, making extending 3rd party native applications (like the Windows shell) very problematic because what version of the CLR that was loaded into a process would depend on the first extension loaded. If the first extension loaded was a .NET 1.1 assembly then any other extensions loaded requiring .NET 2.0 would subsequently fail.