Cyclic dependencies between DLLs

What are the "best" techniques regarding circular dependencies between DLLs in .net?

I am trying to work with error handling / logging DLLs that need to read / write XML.

I already have a few classes to help with XML processing in a separate utility DLL.

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

I thought I should maintain a separate DLL for reuse in other projects, but now I'm not sure what the best approach would be.

Any suggestions on how to handle this scenario?

+3


source to share


2 answers


One way to transfer it is to combine one part into another part of the assembly. My experience is that people tend to fragment their project into many small assemblies that don't really improve anything, but cause dependency problems.

I generally favor very few large builds. Use assemblies as a unit of deployment, don't structure your code. Structure your code with namespaces.



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

+8


source


Here are two White Papers to delve deeper into the topic of Partitioning Code in .NET Assemblies and Namespaces, covering the causes and ways of circular dependencies. It goes in the same direction as usr: very few large assemblies, use assemblies as a deployment unit rather than structuring your code. Structure your code with namespaces.

Splitting the Code Base Through .NET Assemblies and Visual Studio Projects (8 pages)

  • Common valid and invalid reasons for creating an assembly
  • Improve compilation performance of Visual Studio solutions (up to x10 faster)
  • Organization of the development environment


.NET Namespaced Components Definition (7 pages)

  • Defining Components Inside .NET Collectors
  • Acyclic plot of dependencies between components
  • Evolutionary design and acyclic component
+6


source







All Articles