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.
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?
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
There are 2 things here:
1) do you consider assemblies as component? You should not, I explain my stance here: Advices on partitioning code through .NET assemblies
2) whatever you consider as a component, cycles amongst components are harmful, I explain my stance here: (Section: Why are dependency cycles harmful ?) Control component dependencies to gain clear architecture