title: Is an assembly that contains a single class overkill?
body: <p>I'm writing an app which plays host to a series of plug-ins. Those plug-ins generally use two libraries <code>.Common</code> and <code>.UI</code> which contain the interfaces that the plug-ins need to implement etc.</p>
  
  <p>I am now at the point where I'm adding the capability for plug-ins to be subject to licensing.  I have modified my host application such that it will only load plug-ins which define an interface instance (<code>ILicenseInfoProvider</code>) and export it through MEF. That bit is fine.</p>
  
  <p>We have a selected provider of licensing code, and their licensing system involves use of a library. Now, I don't want to <em>force</em> each plug-in to be licensed through that system, and, by extension, require a reference to that system's assembly. So, I am planning on putting the code that references the third-party library in it's own assembly (something like <code>.Licensing.Vendor</code>). This way plug-ins can simply add a reference to that assembly, and include a class that looks somewhat like this:</p>
  
  <pre><code>[Export(typeof(ILicenseInfoProvider))]
  class MyAssemblyLicenseInfoProvider : BaseVendorLicenseInfoProvider
  { 
      public MyAssemblyLicenseInfoProvider() : base("My Assembly's Product Name")
  }
  </code></pre>
  
  <p>I'm reasonably happy with that set-up, apart from one niggling thing - which is that the <code>.Licensing.Vendor</code> assembly will only contain a single class, which is the <code>BaseVendorLicenseInfoProvider</code> relating to the specific licensing system in use.</p>
  
  <p>So, after all that, my question is pretty simple:</p>
  
  <p>Does it seem overkill to put that class in it's own assembly, or is the benefit of not forcing all plug-ins to hold a reference to the third party library worth it?</p>