Normal
0
21
false
false
false
FR
X-NONE
X-NONE
I got some requests from
NDepend users that wish to…
- Analyze the .NET Framework
code base - Compare .NET Framework
versions
…by themselves, as I did
for .NET Fx v4.0 beta1 and .NET Fx 3.5 SP1. For example David Morton recently compared with NDepend, Windows Form v2 and Windows Form v4 beta1.
Amongst all .NET code base,
the .NET Framework is special and thus require special care to be analyzed by
NDepend. This is what I would like to explain in this post.
Let’s have a quick reminder
about where .NET framework assemblies are stored on your machine. Actually
there are 2 locations that contains .NET Framework assemblies:
- The Global Assembly Cache
(GAC) - some sub-folders of C:\Program Files\Reference
Assemblies\Microsoft\Framework and C:\Windows\Microsoft.NET\Framework.
The .NET Framework
assemblies are loaded from the GAC at runtime by the CLR. The non-GAC versions
are used by VisualStudio to reference .NET
Framework assemblies from your VisualStudio project. VisualStudio doesn’t deal
with the GAC.
NDepend project references
.NET Framework assemblies the same way as VisualStudio projects does:
from the
non-GAC location. This references are needed to locate and analyze .NET
Framework assemblies referenced by the application assemblies to
analyze. This way, if your application is using System.Text.StringBuilder for example, NDepend will let you know where it is used in your code and which members are used. More on this topic in this post: controlling the usage of libraries with NDepend.
In order to relieve NDepend users
from the burden of referencing .NET Framework assemblies manually, NDepend
locates automatically the folders that contain the highest version of the .NET Framework installed on the machine. This can be shown in VisualNDepend > Project Properties > Code
to Analyze > expand the Show Folders button. On the picture below you see the
3 folders that contains the .NET Framework v3.5 assemblies. A combo box .NET Framework targeted let’s choose
any .NET Framework version installed on the machine.
And here comes the
interesting part: if you try to analyze for example mscorlib v4.0 beta1 by drag & dropping it in the list of assemblies
to analyze, NDepend will add the folder containing the 4.0 version. NDepend will
detect that 2 different versions of mscorlib
can be found: mscorlib v2.0.xxx and mscorlib v 4.0.xxx. This is shown in the
screenshot below:
Actually, this versioning conflict issue
detection is a cool bonus feature of NDepend. It means that if your
development shop is not clean and contains different versions of the same
assemblies (in the set of folders that contains assemblies of your application), NDepend will let you know. As a side-note, you won’t have conflict between Debug/Release versions of a same assembly since you will very likely analyze only Debug assemblies or only Release assemblies.
To analyze mscorlib v4.0, you just have to remove
improper folders and keep the v4.0 one.
Personally I prefer copying
all .NET Framework assemblies of a given version in a dedicated folder to be
able to analyze them at whim in the future, for future comparison for example. The
only non-trivial step here is to make sure to remove .NET Framework folders added
automatically by default by NDepend.
Now you can enjoy exploring the structure, the quality and the evolution of the .NET Framework by yourself [:)]