In my post about the new Interactive Code Dependencies Graph feature of NDepend, I explained how to use the Indirect Mode of the Dependency Matrix to obtain some Graph of path from 2 code elements, from A to B. I also explain how to obtain some Graph of a cycle involving 2 code elements. By code element, I mean assembly, namespace, type, method or fields and the 2 code elements are not necessarily of the same kind. You can be interested in getting a path from a method to a type for example.

The following Dependency Matrix in Indirect Mode tells that the assembly System.Data is indirectly using the assembly System.Drawing with a minimal depth of 4. By clicking the cell you instantly get a path of depth 4 shown in the Graph panel on the right.

In the comment of the Interactive Code Dependencies Graph post, Sidar asked:

Can I see all the paths in path graph instead of shortest one?If I can, it will be a really useful thing to identify and reduce YAGNI s.

And indeed yes you can thanks to the flexibility of Code Query Language (CQL). With CQL you can readily enumerate all assemblies (directly or indirectly) used by System.Data AND that are (directly or indirectly) using System.Drawing. For this, you just have to write the following query:

Interestingly enough, the Query Result panel automatically displays the values for the 2 metrics DepthOfIsUsedBy “System.Data” and DepthOfIsUsing “System.Drawing”. NDepend automatically infers all metrics involved in a CQL Query. Notice also the ASSEMBLY prefix used in code element name to avoid confusion with the 2 namespaces also named System.Data and System.Drawing.

Logically, all paths from System.Data to System.Drawing involve only these 14 assemblies. To get all paths from System.Data to System.Drawing you then just need to export these 14 assemblies to a Graph by clicking the Export to Graph button in the Query Result panel (right click the row 14 assemblies matched). Et voila:

The funny part is that until Sidar asked if it was possible, I admit that we never thought about the possibility of All Paths from A to B. It is accidentally possible, as many things we didn’t forecast, thanks to the flexibility of NDepend. The same story happened in the past when Jim Bolla explained how to use NDepend to write CQL rules to check for Separation of Concern but also for many CQL queries like when Gaël Covain is using some CQL regular expression to match methods and types with lengthy names (btw these queries have been since added in the list of default CQL rules under the Naming Convention group).