Normal 0 21 false false false FR X-NONE X-NONE

Let’s have a look to see what the tool NDepend shows when comparing .NET Fx v4.0 beta1 assemblies with v3.5 SP1 ones. I will use a few CQL Queries to get fact from the code base of the Framework.

A view of the work achieved

SELECT METHODS WHERE CodeWasChanged OR WasAdded

The following treemap shows in blue, new methods (i.e WasAdded) and methods that have been refactored (i.e where CodeWasChanged). A rectangle represents a method and the size of the rectangle is proportional to the size of the method (in terms of IL instructions). It is pretty impressive to see that a big part of the framework is still evolving, even core stuff in mscorlib and System.

New Core Public Types

SELECT TYPES FROM ASSEMBLIES "mscorlib", "System", "System.Core"

WHERE IsPublic AND WasAdded

221 new public core types, including:

• some concurrent collections in System.Collections.Concurrent 
• the new parallel API in System.Threading and System.Threading.Tasks 
• a new SortedSet<T> collection class, 
• the long time awaited contract API in System.Diagnostics.Contracts 
• a new class System.Numerics.BigInteger (finally!) 
• new support for System.TimeZoneInfo 
• new delegates classes Action<…>, Func<…>, types with highest generic arity (up to 8 generic parameter types) 
• new structures Tuple<…> + System.Collections.IStructuralEquatable/IStructuralComparable/ StructuralComparisons whose main use seems to handle cases where a method return multiples values (not 100% sure on this + I am not sure it is performance wise to use an extra generic structure instead of out/ref keywords in such situation).

Update: I forgot System.Core.dll, here is what's new in this assembly:

• more expression types in System.Linq.Expressions (dynamic, switch, goto, label, try, catch ...)
• Parallel LINQ types in System.Linq (ParallelQuery, ParallelEnumerable...)
• 20 binder types in System.Dynamic
• the new namespace System.IO.MemoryMappedFiles to finally have acess to this cool WIndows feature from the managed world (+associated safe handle types)
  

New Assemblies

SELECT ASSEMBLIES WHERE WasAdded 

I can see 28 of new assemblies but the installation of the .NET Fx assemblies in C:\Program Files\Reference Assemblies\Microsoft\Framework + C:\Windows\Microsoft.NET\Framework is pretty messy and I might have miss some important new ones. However it is worth quoting:

• Microsoft.CSharp.dll: a pretty big assembly that shows only 17 public types related to the dynamic C# 4.0 keyword (see advanced explanations in this post). 
• System.Dynamics.dll : with mainly internal types that seems to represent the internal plumbing to link dynamic invocation with  COM invocation. 
• System.Windows.Forms.DataVisualization.dll, System.Web.DataVisualization.dll that contains the new Microsoft charting API .
• System.Xaml.dll with a new API to play with Xaml explained here.
• System.Activities.XXX.dll and System.ServiceModel.XXX.dll assemblies for WF 4.0 (more info here)  
• System.Caching.dll for a new caching API (code name velocity) exposed here.  
• Microsoft.Build.XXX.dll assemblies apparently for  new (DataDrivenTasks, FileTracker) MSBuild task but I didn’t find more info on this on the web. 
• FSharp.Core.dll apparently, when searching for new assemblies, I missed this big assembly that resides in its own dir C:\Program Files\Reference Assemblies\Microsoft\F#\v4.0

New Public Types

SELECT TYPES WHERE WasAdded AND IsPublic

All in all we have 1 560 new public types. I take a chance here to show a new NDepend v2.12 feature where code elements matching a CQL query can be viewed hierarchically. This feature makes very convenient exploring a large set of code elements matching some criteria, like these 1 560 new public types,.

New Public Namespaces

SELECT NAMESPACES WHERE WasAdded AND IsPublic

In the assemblies considered, NDepend found 89 new namespaces containing at least one public type.

Rambling on the .NET Fx evolution

The .NET framework is getting richer but bigger. Getting richer is positive, because programmers can benefit from more API with the level of support of Microsoft. But I see some issues now:

• Bigger code means more CPU for loading and more precious in-process memory to host code. For example, just using the new dynamic feature will results in loading 2 assemblies (Microsoft.CSharp.dll 478KB + System.Dynamic.dll 119KB) + code compiled natively, so at least 1MB. One lesson learnt from the Vista fiasco is that programmers cannot count anymore on better hardware. Nowadays the doing more with less tenet makes more sense than a decade ago. 
• I didn’t include that in the comparison analysis, but there and there I saw several assemblies suffixed with v3.5 and v4.0. Microsoft addresses one by one flaws of the past, which is great, but this means more overridden code kept for ascendant compatibility only (non generic collection, old threading API, .NET Remoting…). The Fx keeps the trace of its history. 
• A bigger Fx means also more complexity for programmer to tackle it. While the core of the Fx (mscorlib + System) is still pretty neat, seasoned programmers cannot master anymore all aspects of the Fx (Winform + WPF + ASP.NET + WCF + WF + ADO.NET + Entity Fx…). 
• By developing a tool like NDepend we are stuck working with .NET Fx 2.0. When you are an ISV targeting multiple clients worldwide it is still too early to assert that the bulk of users have .NET Fx 3.5 installed. Hopefully some new features are available on .NET Fx 2.0 like contract and some LINQ stuff, but they are more the exception than the rule.

All in all the grow of .NET Fx is a bless for programmers. We must keep in mind that today, if one is using a tier charting API for example, this API require more code loaded at runtime + learning process of the API. By extending the .NET Fx with new features like a charting API, Microsoft is aggregating features that would require resources anyway.

The question is: should the Fx grows indefinitely? What would a .NET Fx v10 look like? What are the plans of Microsoft for the long-term, for the next 10 years?