Home/ Questions/Q 151047
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T09:23:15+00:00

I’m designing a re-usable class library that contains 2 assemblies (amongst others) named core.xml.dll

  • 0

I’m designing a re-usable class library that contains 2 assemblies (amongst others) named core.xml.dll and core.string.dll.

The xml assembly references the string assembly in order to use some string helper methods.

However now there is an string method that would be benefit from using a method contained in the xml assembly.

If I reference the xml assembly from the string assembly I will have created a circular dependency and will be unable to build both assemblies from source code. (ie chicken and the egg problem).

In order to follow the ‘Don’t Repeat Yourself’ principle I would like to avoid duplicating the functionality in both assemblies. If I find a bug in the implementation I only want to fix it in one place.

While I could merge the assemblies into one, this is not ideal as it reduces the cohesiveness of the assembly.

I would need to re-build and re-deploy the entire assembly just for a small change to a specific class. Also, eventually, with so many dependencies I would probably end up with one huge library assembly.

So in the context of a re-usable set of library assemblies what is the best approach to use here? Also, how does the .NET framework itself deal with this issue?

(In Reflector it appears that System.Configuration.dll references System.XML.DLL and vice versa. Is this actually correct, if so how is the circular dependency managed?)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Agree with Knives. Circular depedencies is a design smell. Refactor it Mercilessly!

    This can be challenging in the case where business objects are tightly coupled. In most cases this can be solved through dependency injection.

    Pseudo C++ Example:

    class Employee {     Company company; };  class Company {     vector<Employee> employees; };

    Tricky? Not neccesarily: 

    template<class CompanyT> class Employee {     CompanyT company; };  class Company {     vector<Employee<Company> > employees; };

    More primitive types, which must depend on a higher level, can be abstracted to work with any sort of other type, so long as it fulfills its contracts.

    • 0