

You can make this even easier if you add a “Publish Database” profile to your project. Give it the /TargetServerName for the SQL Server instance.

Tell it what to name the database using /TargetDatabaseName. Specify the /SourceFile and point it to the *.dacpac. Pretty easy, right? Set the /Action to Publish. If I wanted to deploy this database to an instance of SQL Server named demo2012util, here’s what my command line syntax would be: Thankfully, IMHO, SqlPackage.exe is about a trillion times easier to work with. Hello, *.dacpac.)įor this blog post, let’s assume a very simple SQL Server Database Project called (as shown in Figure 1) that, upon “compile”, generates a dacpac file named “”. Especially, since the outputs of database projects have completely changed.

There were a lot of updates for the VS2012 version of the SQL Server Database Projects so it makes sense that vsdbcmd would get tweeked, too. Are you a big user of the SQL Server database projects? You know…what used to be known as ”data dude”? Did you get way into doing command line deployments of your databases using vsdbcmd.exe? Well, if you are one of those developers and you’ve upgraded to the latest version of the SQL Server Database Projects, then you might be wondering just where vsdbcmd.exe went.Īnswer: vsdbcmd.exe has been replaced with SqlPackage.exe.
