In part 2.0 of this series I emphasize on the framework itself and the common language runtime.
Parallel programming and concurrency in LINQ
It was the major gripe of Java developers over .NET developers: parallel programming and concurrency are a pain, unless you were using Java. You were bound to use synchronization primitives to solve your own problems. That has come to an end. Finally, parallel programming has made a giant leap forward in the .NET world with direct support from the Common Language Runtime for higher order parallel functions. Consider the following snippet from PLINQ (Parallel-LINQ):
// possibly drinks alcohol at the party var drinksAlcohol = from member in partyMembers.AsParallel(); where member.Age >= 16 select member;
As you can see, it looks much the same as any LINQ query. If you want to find all members that may drink alcohol at a party (in Europe!) and your list is rather long, then simply adding .AsParallel() to your list will “opt-in” to use the Parallel LINQ libraries. The CLR will take care of the rest, which means making use of multiple CPU cores if possible. These libraries are compiled into System.Core.dll and are now part of System.Linq. Here’s a nice introduction to PLINQ by Daniel Moth.
Parallel programming with the Task Parallel Library
There’s more than just AsParallel() and PLINQ. If you need to use parallelism inside non-LINQ code, you can use the Task Parallel Library, which fills this gap. It will help you create for- and for-each loops that can make use of parallellism. This is an extensive library, but the main entry point will be the Parallel or the Task class which make heavy use of lambda expressions that were introduced in C# 3.0. Just a look under the veil:
// a for-each loop using TPL Parallel.ForEach(partyMembers, member => DoSomething(member)); // a new parallel task without explicit threads Task.Factory.StartNew(() => DoSomething());
At devx.com there’s a quick getting started page that introduces multi-core programming using the Task Parallel Library (TPL).
Multi-targeting and side by side execution of .NET 2.0, 3.0, 3.5 or 4.0
Both the framework and the IDE includes major improvements to support multi-targeting better. In Visual Studio 2008 you would still see the methods of .NET 3.5 in IntelliSense, even if you targeted .NET 2.0. This has been fixed. The main trick that VS 2010 did to support this is to add all .NET Framework versions in the Visual Studio package as metadata assemblies. These contain only what is inside a .NET Framework version which made loading the intellisense much lighter and paved the path for real multi-targeting support. Scott Guthrie has an excellent in-depth article on all the features that multi-targeting supports.
What’s particularly interesting is the possibility to run several version side by side in the same process space. This was already possible with .NET 1.0 and 1.1 but later versions dropped that support. Finally it has made it reintrance to the framework. Read a series of articles on the subject.
Dynamic Languages Support with the DLR
There’s a new kid in town. It’s called the DLR, not a typo for CLR. The D is for Dynamic and opens the path for dynamic languages. These are languages like IronPython, IronRuby or F# (the latter not being a dynamica, the upcomings of which Microsoft considered including native support in the CLR. As a result, those three languages are now fully supported. Most eye-catching are the BCL-level support of BigIntegers and Tuples which have always had a specific place in dynamic languages.
A summary of other improvements of the .NET Framework
- When two equal types in different libaries share the same IID they will be treated as the same type by the CLR to improve COM compatibility. See Advances of the .NET Type System which discusses the PIA problem and the NoPIA solution.
- The Garbage Collector (GC) has received significant improvements for the first time since version 1.0 of the framework. Most of it are good for performance reasons, here’s a quick summary.
- Huge improvements to the CLR ThreadPool, Eric Eilebrecht has a series of articles that discusses these in depth.
- Code Access Security is deprecated now. A great feature but too complex and little understood is superseded by Security Transparency.
- XSLT profiling and debugging. Note that this is still only XSLT 1.0, the version of XSLT that many people dislike for the lack of functionality. The superior XSLT 2.0 with XPath 2.0 and XQuery are still not supported by the .NET Framework (see also the comment by John Brea in this blog post on BizTalk Server).
If not for anything else, just the parallel execution possibilities finally offered in this new .NET Framework release are worth their while to seriously consider upgrading. Microsoft has traditionally been slow compared to the competition when it comes to concurrency and parellellisation. 10 years after multi-cores became mainstream and 10 years after the original release of .NET it’s time to consider this version a mature .NET version. Let’s only hope it proves as stable as the previous versions.
If you miss your favorite feature in this list, don’t hesitate to leave me a comment and I’ll consider updating my post.