title: Circular dependencies versus DRY
body: <p>I'm designing a re-usable class library that contains 2 assemblies (amongst others) named core.xml.dll  and core.string.dll.</p>
  
  <p>The xml assembly references the string assembly in order to use some string helper methods.  </p>
  
  <p>However now there is an string method that would be benefit from using a method contained in the xml assembly.  </p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>While I could merge the assemblies into one, this is not ideal as it reduces the cohesiveness of the assembly.  </p>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>(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?)</p>