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.
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
Same as any other circular dependency...
Consider three assemblies A, B & C
A needs something defined in B, B needs something defined in C, and C needs something defined in A.
Which can you build first?
I am one of the developer of the tool NDepend for .NET developers that is specialized in enforcing clean code structure and remove dependency cycles. On our product site you'll find two white-books relative to the component dependency cycle issue:
Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)
Defining .NET Components with Namespaces (7 pages)
