New Tools for Framework Designers Published

Mircea recently published a set of tools we have been using recently in design and Architecture reviews of the .NET Framework.  image

You can download the three new tools Deps, Layering, and potentialCallers here:

https://code.msdn.microsoft.com/fxarch 

Enjoy!

 

Deps

Deps.exe constructs the dependency diagrams between assemblies, and carries out cycle detection analysis.

The command line format is:

deps.exe {d|s} <mscorlib_path> <path_list> [:assembly_name]

Example:

deps s c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll c:\Windows\Microsoft.NET\Framework\v2.0.50727 :System

The tool produces the files:

  • Full.dot. This is a graphviz – formatted file containing the inter-assembly dependencies, based on what each assembly declares as its references.
  • Api.dot. This is also a graphviz formatted file containing inter-assembly dependencies, but only those that are based on the non-private API signatures of public types. This includes the types themselves (i.e. a type A inheriting from a type B defined in another assembly will cause a dependency arc between these assemblies)
  • Full.txt. This is a text file showing which assemblies can be reached from each assembly, and whether there are cycles (the “True/False” statement)
  • Api.txt. Similar to above, but based on API-only dependencies.
  • Assembly_name.full.dot and Assembly_name.api.dot – if the :assembly_name option was specified, 2 graphviz files containing just the given assembly and its dependencies.

If the tool cannot find a dependency in the paths provided, it will record the assembly between square brackets, as such: [something]. Mscorlib is also recorded like that.

The tool additionally outputs some general-interest statistics (e.g. number of types, number of members, etc).

Layering

Layering.exe verifies that some assemblies respect an architectural diagram.

The command line format is:

Layering.exe <diagramFile> <mscorlib> <dirs>

The tool also outputs a file called “graph.dot” which shows the relations between groups within a layer and, between layers, the dependencies that violate layering. The file can be processed by graphviz.

The file consists of layer definitions. Each layer is defined by groups. Each group is defined by a list of managed binaries.

Each layer has an order. No 2 layers may have the same order. The tool considers it a violation if there are assemblies in a lower layer depending on assemblies in a higher layer.

Each group has an order. Two groups may have the same order. The tool considers it a violation if there is a dependency from a lower group to a higher group (in the same layer), or between groups of the same order (also, within the same layer).

PotentialCallers

PotentialCallers shows the list of methods that may (directly or indirectly) make a statically-determinable call to any one of the methods in a given set. To reiterate: no virtual calls are analysed.

The command line format is:

potentialCallers <methods> <mscorlib> <dirs>

The tool outputs at the console the list of direct calls that leads to calling any of the methods in the list. The output may be captured and then processed by graphviz.

To explain the output further: a call A->B means that method A makes a call to method B. If method B is in the set, then the fact that the call needed to be included is immediate. If B is not in the set, it means that B’s control flow touches one or more of the methods in the set.

The full output of the tool will contain all the segments in the call path between any method and a method in the given set.

Comments

  • Anonymous
    August 03, 2008
    PingBack from http://blog.a-foton.ru/2008/08/new-tools-for-framework-designers-published/

  • Anonymous
    August 03, 2008
    Excellent! Thank you very much guys, this is great work. To be honest I am not going to throw away my NDepend yet (actually I reckon the layering tool makes a great complement to NDep), but then NDepend doesn't come free, so again thank you.

  • Anonymous
    August 03, 2008
    Thank you for the tools why the tools is not open source ? Thanks

  • Anonymous
    August 03, 2008
    How does these tools differ from the architecture tools in the next version of Visual Studio?

  • Anonymous
    August 04, 2008
    @max, why should they be open source?

  • Anonymous
    August 04, 2008
    @kementeus, so we can learn more and get more benefit :-)

  • Anonymous
    August 04, 2008
    It appears that there is a dependancy on FSharp that is not included.  I have sent the error on through.

  • Anonymous
    August 05, 2008
    The comment has been removed

  • Anonymous
    August 10, 2008
    【原文地址】 New Tools for Framework Designers Published 【原文发表日期】 03 August 08 02:53 Mircea近期发布了一套新工具,这也是我们近来对