2

I'm sure we've all been in the situation where we've inherited code that was "overly public", becomes obsolete or needs to be refactored. In these situations, it is easy to spend many days analysing the API surface to see where methods or classes are consumed; with the .Net runtime, it seems logical that it should be relatively trivial to map these inter-assembly dependencies, but there doesn't seem to be any tools out there that do this already?

For example, let's suggest that we have a CRM class library that encapsulates the interface to all the customer data; it's not unreasonable that a quotations application may rely on this, but it seems non-trivial to identify on which bits. A naive approach would be to say that the public interfaces (types, etc.) is the API surface, but it may be the case that some of these interfaces are only public for consumption in a particular use case, that may become invalid.

Is it possible to automatically determine and map the inter-assembly dependencies for a given set of assemblies?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Rowland Shaw
  • 338
  • 1
  • 11

2 Answers2

2

Static analysis tools like nDepend do this.

It has views that tell you what types are used where and how often, recognized circular dependencies and more.

Oded
  • 53,326
  • 19
  • 166
  • 181
  • As far as I can make out from their feature comparison, this works on a solution level, rather than "set of assemblies" level – Rowland Shaw Feb 28 '12 at 15:22
  • 1
    @RowlandShaw - No, it analyses assemblies. – Oded Feb 28 '12 at 15:25
  • Well, the trial version is suitably unhelpful to confirm what I knew were dependencies in my code, but it does seem to have missed a load too, which is worrying. Perhaps I'd be better off writing something myself using the reflection APIs "at some point". – Rowland Shaw Feb 28 '12 at 17:09
0

I'm sure you could identify some of the dependencies, but not all. E.g., what about a web service call that's either dynamically generated or read from a resource?

TMN
  • 11,313
  • 1
  • 21
  • 31
  • A webservice is actually fairly easy to define the API surface, as it would be decorated with appropriate attributes, although that's not my use case to be analysing today – Rowland Shaw Feb 28 '12 at 17:07
  • I meant if you had a system A whose API you were analyzing, and some system B was making web service calls to A, it might be hard to determine which web services were being called if system B was dynamically generating the service URI was or was creating the service call from a template stored in a database or resource file. – TMN Feb 28 '12 at 19:07
  • But then the web service portions would be suitably decorated, and obvious as part of the public API surface. – Rowland Shaw Feb 28 '12 at 19:28
  • But how would you know whether it was used, or whether you could safely remove it to reduce your API exposure? – TMN Feb 29 '12 at 13:20
  • If that API had been **published**, then it is **never** safe to remove it. In my use case, there is no *published* API surface. – Rowland Shaw Feb 29 '12 at 13:43