title: C# .net - Dll Naming Conventions in Interface / Implementation Scenarios
body: <p>I need some suggestions for clever naming of dll and/or a hint if any naming conventions for the following scenario exist. </p>
  
  <p>I have an interface definition and several types used by that interface definition encapsulated in one dll. Then I have an implementation of this interface in another dll. 
  The “special” thing about this situation is that I do not develop an application but more a collection of functionalities (aka framework) that is used by multiple applications of my company. These functionalities are accessed through its interface definition via MEF, so the user of this framework does usually not know, nor is it important to him, in which dll the implementation is (since he only needs to know and reference the dll containing the interface definition). Just in really uncommon cases he might want to know how the dll (the one containing the implementation) is named, because he wants to replace the implementation with his own. </p>
  
  <p>I created some requirements for my dll naming:</p>
  
  <ul>
  <li>The dll with the interface definition needs to be well named because this is the dll the user is referencing.</li>
  <li>The namespace of the interface definition dll needs to be very well named (and be very intuitive) so the user really expects this definition in this namespace, where it would be the optimum that the namespace equals the solution structure.</li>
  <li>The implementation dll must be named very clear, so the user can identify the dll in the working directory to remove it and install an own implementation.</li>
  <li>The namespace of the implementation does not really matter since its only used internally.</li>
  <li>The dll names should not be too long.</li>
  </ul>
  
  <p>First, I came up with the idea to group all interface definitions of a specific type in one dll, that would create a very well named namespace since I can group for example all “services” in a dll called MyCompany.Services.dll, put all definition and types in that root (which creates the namespace MyCompany.Services), and therefore have kept the solution structure equal to the namespaces (which might be alo discussed here if this is useful or not). </p>
  
  <p>But that generates a big problem: </p>
  
  <p>If I signature the dlls and change something in my MyCompany.Services.dll, I have to recompile all implementation dlls even if this change only affects one of this n dlls. At that point I thought about putting each interface definition and ity types in an own dll (as described in the beginning of this post).</p>