title: Why does using Microsoft Sql Server Management Objects (SMO) in the DAL require references to SMO dlls in a project which references the DAL?
body: <p><strong>I've searched for an answer on google using:</strong></p>
  
  <p>"The type 'Microsoft.SqlServer.Management.Smo.Server' is defined in an assembly that is not referenced."</p>
  
  <p>Why does using Microsoft Sql Server Management Objects (SMO) in the DAL require references to SMO dlls in a referenced project?</p>
  
  <p>using sql smo in referenced projects</p>
  
  <p>sql smo in layered solutions</p>
  
  <p>sql smo reference requirements</p>
  
  <p>and probably a few others and have not found a solution or explanation to this issue.</p>
  
  <p>Admittedly, I'm only a journeyman googler, so if someone wishes to power level me and point the way to an existing resource, I'll gladly go spelunking from there.</p>
  
  <p><strong>Here's my set up:</strong></p>
  
  <p>I've got a layered solution: DAL, Business Logic, Services, UI.  There's a hosts project that hosts the services.  I'm actually using the VS2010 extension <a href="http://layerguidance.codeplex.com" rel="nofollow">layerguidance.codeplex.com</a>, which is quite nice, to set up all these projects.  I'm using SQL Server 2008 Express and SMO v 10. All solution projects are referenced using Project References.  All projects compile to a common top level Bin folder.</p>
  
  <p><strong>Now the problem:</strong></p>
  
  <p>Among the classes in the DAL I have an <code>SmoTasks</code> class which handles interfacing with SMO objects and a <code>Utilities</code> class which abstracts from <code>SmoTasks</code> and provides acces to its functions without requiring any SMO objects for parameters, so that referencing projects (read: Business Logic Layer) can interface using non-SMO types.  All is well in the DAL, it compiles fine, the methods pass their tests - it feels good about its place in my world.  Then in the BLL I have a component which handles using the <code>Utilities</code> class to perform database configuration for the application which will be exposed via the services.  The BLL uses a project reference to the DAL and sees the DAL classes (a la intellisense) as expected.  When I compile though, I get:</p>
  
  <p><strong>The type 'Microsoft.SqlServer.Management.Smo.Server' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'.</strong></p>
  
  <p>The code in BLL looks like this:</p>
  
  <pre><code> public bool CreateTables(string connectionString)
      {
  
          bool result = default(bool);
  
  
          // Data access component declarations.
          Utilities utilities = new Utilities();
  
          // Step 1 - Calling CreateTables on Utilities.
          result = utilities.CreateTables(connectionString);
  
          return result;
  
      }
  </code></pre>
  
  <p>The line the error points to is:</p>
  
  <pre><code>result = utilities.CreateTables(connectionString);
  </code></pre>
  
  <p>I could, obviously, add the SMO references to the BLL and then the BLL would be happy, but that violates my design goal of loosely coupled projects.  If I add the SMO assemblies to the BLL, it compiles and then referencing BLL objects in the services layer doesn't cause a complaint.  My question is, why? More specifically: <strong>Why does the BLL need references to SMO when the <code>Utilities</code> class in the DAL already abstracts away the SMO types?</strong></p>
  
  <p>What I want is everything database related to live in the DAL (duh) and only business logic  in the BLL (double duh).  <strong>Is there another way to achieve this using SMO that I have overlooked?</strong></p>
  
  <p><strong>Thank you for your valuable time and answers, I humbly await your responses</strong></p>
  
  <p>Edit:
  I've adjusted my solution based on suggestions by Chris, verified that I'm using project refs (I am), readded the references to SMO in the DAL using Muse.VSExtensions to add GAC reference, before I had been browsing and adding manually, then I went ahead and set Copy Local = True for those assemblies just to be doubly sure they're around... but I'm still stuck with this annoying compile error.</p>