Circular Dependencies Amongst DLL's

Question

What are the 'best' practices regarding circular dependencies amongst DLL's in .net?

I am trying to work on a DLL for error handling/logging that needs to read/write XML.

I already have several classes to help with XML manipulation in a seperate 'utility' type DLL.

It would be nice to incorporate my fancy-pants error handling classes into the utility DLL, but I also need the XML manipulation code for the error logging DLL.

I was thinking I should keep the DLL's seperate for re-use in other projects, but now I'm not sure what the best approach would be.

Any suggestions on how to handle this scenario?

possible duplicate of [Circular Reference Problem (C#)](http://stackoverflow.com/questions/1318123/circular-reference-problem-c) — RQDQ, Mar 29 '12 at 19:54
xml handling with XDocument (linq2xml) is really simple I don't think you need separated project for this. — Saeed Amiri, Mar 29 '12 at 20:24
What's the point in keeping them separate if they depend on each other? — McGarnagle, Mar 29 '12 at 20:48
sideways thought -- are you supporting a legacy logging system that uses XML? You might want to look at log4net -- it can log to XML, plaintext, email, event-log, etc. https://logging.apache.org/log4net/ — Michael Paulukonis, Mar 30 '12 at 14:25
related: https://softwareengineering.stackexchange.com/questions/348162/benefits-of-circular-references — StayOnTarget, Oct 26 '18 at 12:59

score 10 · Accepted Answer · answered Mar 29 '12 at 20:38

One way of handing it is to merge one part into the other part's assembly. My experience is that people tend to fragment their project into lots of small assemblies which does not really improve anything but causes dependency problems.

I generally advocate very few big assemblies. Use assemblies as a unit of deployment, not to structure your code. Structure your code using namespaces.

A different way to fix this is to introduce interfaces, either in a common assembly or in one of the two existing assemblies. The latter case makes sense if the interface methods themselves do not have a circular dependency but the method bodies do.

Thanks - I was beginning to think that I was breaking things up into too many pieces. I think I will go with a single larger assembly, but seperate out the different concerns with namespaces. Thanks! — ChandlerPelhams, Mar 29 '12 at 21:23

score 8 · Answer 2 · answered Apr 02 '12 at 13:24

Here are two White-Books to dig deeper in the topic of partitionning code in .NET assemblies and namespaces, covering the why and how of circular dependencies. It goes in the same direction as usr suggests: very few big assemblies, use assemblies as a unit of deployment, not to structure your code. Structure your code using namespaces.

Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)

Common valid and invalid reasons to create an assembly
Increase Visual Studio solution compilation performance (up to x10 faster)
Organize the development environment

Defining .NET Components with Namespaces (7 pages)

Defining components inside .NET assemblies
Acyclic graph of dependencies between components
Evolutionary Design and Acyclic componentization

Circular Dependencies Amongst DLL's

2 Answers2