Comparing Silverlight and the .NET Framework

A recent NDepend v2.10.2 feature is the analysis of Silverlight application. Silverlight recently went from beta to 2.0 Release
Candidate 0
. In this blog post I will first
compare Silverlight 2.0 RC0 and .NET Framework v3.5 SP1 assemblies. I
will then compare Silverlight 2.0 RC0
and Silverlight 2.0 beta assemblies.
To do so, I’ll use the Build Comparison feature
of NDepend.

 

 

Silverlight 2.0 RC0 vs. .NET Framework v3.5 SP1

 

Let’s notice first that
only the following assemblies can be compared: mscorlib, System, System.Core, System.Net, System.Runtime.Serialization,
System.ServiceModel, System.ServiceModel.Web, System.Xml. While the .NET Framework has numerous other
assemblies not supported by Silverlight,
Silverlight comes with only 2 assemblies
not present in the .NET Framework: System.Windows.Browser and System.Windows. Another detail: the
assembly System.dll had been renamed
(I think by mistake) system.dll in Silverlight?!

 

SELECT TYPES WHERE IsPublic AND WasAdded

Silverlight has 44 new public
types
.
41 of them are in the assembly System.Net,
and the public class System.Xml.XmlXapResolver
and the 2 enumerations System.Xml.DtdProcessing,
System.Xml.NamespaceHandling
are in the assembly System.Xml.
Interestingly enough, it is easy to see that these System.Net types are in the assembly System of the regular .NET
Framework
. So the decision has been to move these types.

 

SELECT METHODS WHERE WasRemoved

By visualizing the .NET Framework methods removed in Silverlight with the NDepend metric/treemap
view, it is really obvious that Silverlight
is a mini-mini-.NET Framework (methods removed are in blue).

 

 

 

For the concerned
assemblies, 8 129 types on 9 989 have been removed. It is even more impressing
in terms of methods, 72 515 methods on 90 574 have been removed. In terms of IL
instructions, 1 607 974 IL instructions on 2 046 294 have
been removed, around 78.5%!. It is interesting to list the 100 namespaces that
have been completely discarded in Silverlight
.

SELECT NAMESPACES WHERE WasRemoved ORDER BY NbTypes DESC, NbILInstructions DESC

 

Concerning dependencies, Microsoft did the work of removing many
dependencies to .NET Framework assemblies not part of the Silverlight release. This can be shown with the following graph,
where .NET Framework 3.5 SP1small
assemblies in yellow are considered by NDepend
as tier assemblies, because they are indeed not part of the list of assemblies
chosen.

 

Concerning Silverlight internal dependencies, the
following Dependency Matrix tells us that hopefully the Silverlight assemblies are layered, which is not the case of the
regular .NET Framework. For example in
the regular .NET Framework mscorlib.dll and System.dll are mutually dependent.
Notice that we infer from the following matrix that there are no cycles between
assemblies of Silverlight, because
the matrix is triangularized. Moreover, cells with a red tick
represent dependencies between assemblies that have been changed (basically all
of them). Cells with a red tick and a plus/minus,
dependency represent dependencies between assemblies that have been created/removed especially for
Silverlight.



Here is the same set of Silverlight internal dependencies
represented with a graph. Here, we infer from the graph that there are no
cycles between assemblies of Silverlight,
because the graph is perfectly layered from top to bottom (i.e there are no
rows that goes from bottom to top).

 


Silverlight 2.0 RC0 vs. Silverlight 2.0 beta

The delta between Silverlight
beta and RC0 is significant.

 

SELECT TYPES WHERE IsPublic AND WasAdded

73 public types have been added
(a lot of controls)
.

 

SELECT TYPES WHERE IsPublic AND WasRemoved

11 public types have been
removed.

 

By looking at the metric
view for methods added or refactored, it is pretty clear that a lot of work has
been done on controls in System.Window (methods added or refactored are in blue):

SELECT METHODS WHERE CodeWasChanged OR WasAdded


 

Analyzing your Silverlight application with
NDepend

 

To make possible Silverlight assemblies analysis, we
needed to tweak a bit how NDepend
resolves .NET Framework assemblies.
Indeed, not only NDepend analyzes the
code of your application, but also the code used by your application, what we
call Tiers Code. And the .NET Framework code (mscorlib,
System.Core…) is by-design tier code
for all .NET applications since all .NET Assemblies references mscorlib.dll (except mscorlib.dll itself [:)]).

 

As shown below, we added
the possibility to choose the .NET
Framework
targeted. There is no magic behind this, but just the
modification of the list of folders that contain the .NET Framework assemblies.

 

As you can see on the
screenshot above, NDepend references Silverlight beta assemblies version 2.0.30523.8. Silverlight RC0 has the version number 2.0.30923.0 and you then need to update the version number as
shown below. Of course the next version of NDepend
will be updated.

 


 

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.NDepend.com Patrick Smacchia

    Yes you are right Rob,
    but so far NDepend can’t see when a type is moved from a namespace or assembly to another. It considers that atype is deleted and then added. But by looking at type added name, you are right indeed.

  • http://www.bluespire.com/blogs Rob

    I believe that Silverlight’s System.Windows assembly contains various types located in the .NET Framework assemblies: WindowsBase, PresentationCore and PresentationFramework. Perhaps some comparison can be made between these?