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:





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]


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.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 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.