SQL SMO assemblies not being deployed when publishing

Question

I've got a little problem regarding the deployment of a number of assemblies related to SMO. I have the following 5 references in my project:

Each one is a .dll in a libraries folder which is where the references were added from and each is set to Copy Local = true. The project file shows all this is in order, for example:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL">
  <HintPath>..\Libraries\Microsoft.SqlServer.Smo.dll</HintPath>
  <Private>True</Private>
</Reference>

Problem is, every time I publish from Visual Studio on my PC, the assemblies aren't copied. Same thing when I publish via TeamCity (which definitely doesn't have SQL Server or the SMO SDK installed). I can copy the assemblies over manually and things run just fine (no GAC dependency), but obviously I'd like to encapsulate this in the deployment process.

What could be stopping these assemblies from publishing?

Answer 1

I believe you're not supposed to just copy DLL when deploying an SMO-based application. See this link: Distributing an Application That Uses SQL Server Management Objects. I quote:

If you develop an application that uses SQL Server Management Objects, you need to make sure that the necessary support files are present on the computer with the application. The SQL Server 2008 feature pack contains a redistributable package for the SQL Server Management Objects.

You will need to get the SharedManagementObjects.msi from this download link: http://www.microsoft.com/download/en/details.aspx?id=16978

Answer 2

Microsoft employee Monica Rivera confirmed in an MSDN thread that it is fine to bundle the DLLs with your application:

Here's another way. You can choose to include the necessary DLLs in your build from the VS project. If you select the reference in the project and change the Property "Copy Local" to True, the corresponding DLL will be included in the build.

So, according to the MSDN thread, both solutions are fine.