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?

Answer 1

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.