.Net Framework 4.0

 Every year the industry develops new technology and new trends. Now Microsoft is again come to provide next version of .net framework i.e. .Net Framework 4.0. As a result MS Visual Studio 2010 is just around the corner with the new innovation in application architecture, development, and deployment. So in this article I am describing some new features coming in the .Net Framework 4.0. Before describing new features of .Net Framework 4.0, I am giving a summary of some of the main functionality in each .net version. 

So you have just seen the major change in each version on .Net Framework. Above figure defines the feature stack of the .Net Framework.  

Following are new features provided by .NET Framework 4.0 – 

• New Languages 

.NET 4.0 will include IronPython, IronRuby, and F#, among others. The three named languages have been available in some form for a few years now, but it appears that with .NET 4.0 they become “official” in the same way as C#, Visual Basic .NET. Both IronPython and IronRuby leverage the Dynamic Language Runtime (DLR), a subsystem that supports dynamic languages on .NET. The DLR has been around for a couple of years now, but with .NET 4.0 becomes an integral part of the .NET runtime. 

In order to support the new languages, and to ensure language interoperability, the CLR team did make some changes. Two additions are particularly interesting to me: BigInteger and Tuple. Because these features are in the base class libraries, all .NET languages can use them 

• Threading improvements 

Framework 4.0 includes the Task Parallel Library (TPL), a library of objects that make it easier to write code that takes advantage of multiple cores. Not only do TPL functions relieve you of the tedium involved with starting and managing threads, they also help you to structure your code to make the most of the computing resources available. 

During development and use of the TPL, the CLR team found a number of areas in which the .NET thread pool (the subsystem that the TPL depends on) was less than optimum. They have since improved the thread pool, giving a performance boost not only TPL programs, but to all programs that make use of .NET threading services.  

• Garbage Collector Improvements 

All in all, the .NET garbage collector is considered a good thing. However, it does have some drawbacks. In particular, it can severely impact performance in some cases.

The server garbage collector in .NET 3.51 and earlier versions is optimized for higher throughput, but has to pause all threads when it does a full collection. The result is that processing comes to a halt whenever a full collection occurs. This can be very annoying. 

The pauses still occur in .NET 4.0, but the system will notify your program before a full collection starts, and notify it again when the garbage collector has finished with collection. In a multi-server environment, you can use this feature to direct traffic away from your server while it’s in the middle of a full collection. That helps with server farms, but doesn’t help with memory-intensive applications that are running on a single machine. 

The workstation garbage collector in 4.0 gets a new background collection feature, which results in fewer pauses and doesn’t require any changes to your code. Only very unusual circumstances will result in the long latency that you might have seen in versions 3.51 or earlier 

• PLINQ 

.Net Framework 3.5 introduced new concept i.e. LINQ(Language Integrated Queries). Microsoft original motivation behind LINQ was to address the impedance mismatch between programming languages and database 

Microsoft LINQ defines a set of proprietary query operators that can be used to query, project and filter data in arrays, enumerable classes, XML (XLINQ), relational database, and third party data sources. While it allows any data source to be queried, it requires that the data be encapsulated as objects. So, if the data source does not natively store data as objects, the data must be mapped to the object domain. Queries written using the query operators are executed either by the LINQ query processing engine or, via an extension mechanism, handed over to LINQ providers which either implement a separate query processing engine or translate to a different format to be executed on a separate data store (such as on a database server as SQL queries (DLINQ)). The results of a query are returned as a collection of in-memory objects that can be enumerated using a standard iterator function such as C#’s foreach. 

Like all constructs in LINQ, PLINQ is based on extension methods, in this case the AsParallel method. Once you’ve built the expression tree representing the query, the AsParallel operation is added at the very end, which tells the “LINQ engine” to figure out parallel jobs and do all of the magic required to make the app benefit from multi-threaded execution. A conceptual example is shown below: 

var result = (from p in db.Products join pd in xml.ProductDescriptions on p.ID equals pd.ID where p.Price > 100 select new { p.Name, p.Price, pd.Description }).AsParallel();