Question

Please describe the .NET assembly compilation circular dependency problem in layman’s terms, and whether other technologes have similar limitations.

Note: This seems like a simple question, I know, but I have seen a number of real, significant projects that have totally broken dependency graphs.

Answer 1

To add to Lucas’s answer: it’s very hard to come up with a circular assembly dependency in .NET. In order to compile A.dll you first need B.dll; to compile B.dll you first need C.dll; but to compile C.dll you need the A.dll you were trying to compile in the first place.

The only way you’re likely to get into this situation is if you’re developing A, B and C in parallel, and you’ve managed to introduce a circular dependency by accident. But as soon as you do a clean build of all three, the problem will be apparent, and you won’t be able to proceed until you break the cycle.

Circular dependencies between namespaces and/or classes within a single dependency are a lot more common. I try to treat this kind of circular dependency as a code smell; a codebase without circular dependencies between components is one where those components can easily be kept separate and refactored independently.

Patrick Smacchia (the NDepend guy) talks a little about dependency cycles and their effect on code quality here: http://codebetter.com/blogs/patricksmacchia/archive/2009/07/29/maintainability-learnability-component-layering.aspx