SQL Server Database Project's Deploy & Publish Targets

Question

There are two distinct targets, Deploy and Publish, in SSDT project alongside Build but I can't find anything on what's the difference between them and which one should be used when? From what I can gather .dbproj used to use Deploy but .sqlproj supposedly replaced it with Publish, how come it's still there and what is it still used for?

$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets

<UsingTask TaskName="SqlBuildTask" AssemblyFile="$(SqlServerRedistPath)\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll" />
<UsingTask TaskName="SqlDeployTask" AssemblyFile="$(SqlServerRedistPath)\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll" />
<UsingTask TaskName="SqlPublishTask" AssemblyFile="$(SqlServerRedistPath)\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll" />

<DeployDependsOn>
    BeforeDeploy;
    PreDeployEvent;
    SqlDeploy;
    PostDeployEvent;
    AfterDeploy
</DeployDependsOn>

<Target Name="Deploy" DependsOnTargets="$(DeployDependsOn)">

<PublishDependsOn>
    BeforePublish;
    PrePublishEvent;
    SqlPublish;
    PostPublishEvent;
    AfterPublish
</PublishDependsOn>

<Target Name="Publish" DependsOnTargets="$(PublishDependsOn)">

Answer 1

The main difference is that Publish is used when you have a publish profile file describing the connection information, whereas Deploy is used when you do not have this file / do not wish to use one. Both are used by SSDT, the Deploy task is not just there for backward compatibility.

The Publish task takes in a "PublishProfile" property that specifies a saved publish profile xml file. The required server name, database name and other properties needed are read from that file. See this forum post for some more information.

The deploy task is used when you do not have a publish profile (for example, the F5 debug deployment uses this, if I recall correctly). I believe this requires that the server, database name and other properties be set explicitly.

Answer 2

I'm assuming it's for backwards compatibility. Upgrading a SQL2008 dbproj to SQL2012 sqlproj after installing the SSDT update, you'd probably still want your dbprojects to function correctly until they are converted.