CODEWITHSUNDEEP
c#.netdllcircular-dependency
ChandlerPelhams
ChandlerPelhams

Reputation: 1678

Circular Dependencies Amongst DLL's

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?

Upvotes: 6

Views: 4534

Answers (2)

Patrick from NDepend team
Patrick from NDepend team

Reputation: 13842

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

Upvotes: 8

usr
usr

Reputation: 171206

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.

Upvotes: 10

Related Questions