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
- 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)
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
- 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
- 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
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
- 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
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?