Analyze and explore the evolution of .NET Framework by yourself

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 and mscorlib v 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 [:)]

This entry was posted in .NET assemblies, .NET Framework, .NET Fx, breaking changes, Build Comparison, Change summary, Changes, Code Diff. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Patrick Smacchia

    Bob, I wrote numerous article on “a real world” example/analysis. Concerning this particular post:

    – it reveals “under the hood’ information about .NET Fx assemblies location/deployment/usage.

    – what this post is about, i.e analyzing .NET fx quality/evolution by yourself, is something that is not treated anywhere else as far as I know (do you know some?).

    – as said, this post answers a request I got from several readers that wanted to analyze the .NET Fx by themselves as I did before.

    I got plenty of positive feedbacks about my original analysis of the .NET Fx and it seems to me that this post will be valuable for many CB readers.

  • Bob

    With all due respect, wouldn’t this type of post be more relevant on a NDepend website?

    Something more relevant to this site would be a blog series on a real world example where someone takes an existing “messy” codebase, analyzes it with NDepend and then proceeds to refactor based on these findings.