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.
Answer: vsdbcmd.exe has been replaced with SqlPackage.exe.
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. Especially, since the outputs of database projects have completely changed. (Goodbye, *.dbschema files. Hello, *.dacpac.)
For this blog post, let’s assume a very simple SQL Server Database Project called Benday.SampleApp.Database (as shown in Figure 1) that, upon “compile”, generates a dacpac file named “Benday.SampleApp.Database.dacpac”.
Figure 1 – The database project
Thankfully, IMHO, SqlPackage.exe is about a trillion times easier to work with. If I wanted to deploy this database to an instance of SQL Server named demo2012util, here’s what my command line syntax would be:
Pretty easy, right? Set the /Action to Publish. Specify the /SourceFile and point it to the *.dacpac. Tell it what to name the database using /TargetDatabaseName. Give it the /TargetServerName for the SQL Server instance. Done.
You can make this even easier if you add a “Publish Database” profile to your project. In Figure 2, you can see the two profiles that I created – one for the “dev” environment named Benday.SampleApp.Database.dev.publish.xml and one for the “prod” environment named Benday.SampleApp.Database.prod.publish.xml. These files contain all the configuration values that you’d use to deploy a SQL Server dacpac into a particular environment.
Since the profile (*.publish.xml) file has all the config values, when you go to deploy the database from the command line using SqlPackage.exe, you don’t have to supply the /TargetDatabaseName or the /TargetServerName anymore and instead you just provide the path to the dacpac using /SourceFile and then specify the profile using the /Profile argument.
Here’s what that command would look like:
At this point, you’re probably sarcastically thinking “WHOOPTEEDOOO!!! I’ve exchanged 4 command line arguments for 3 command line arguments! Think of all the extra free time I’ll have now! Thanks, Ben!” If your deployment arguments are as simple as server instance and database name then yah…not that impressive. But there are a lot more configuration options available to you on the command line and typing/managing all those values will definitely be an annoying and error-prone process.
Just for giggles, try double-clicking on one of those *.publish.xml files. You should see the Publish Database dialog for that deployment profile as shown in Figure 3. This dialog lets you set the target database connection and the database name.
Impressed yet? Not really? Ok. Click the Advanced button. KA-POWWWWWW! Aw snap! You’ve just been pwned! Or whatever the cool kids say in order to indicate that something kinda awesome just happened up. I’m pretty solidly lame. Cut me some slack already. Granddad’s tired. (I’m 38. Practically a senior citizen in the development world.)
ANYWAY! You should now see the Advanced Publish Settings dialog and it should look something like Figure 4. There are a TON of settings that you can…uhmmm…set for your database deployments.
As these settings get complex, it becomes more and more important that these settings aren’t left up to chance and are under version control just like everything else. One of the biggest time savers when it comes to deploying code and databases is having a well-known automated way to deploy where all your config settings are scripted out. If it’s scripted, it’s easy. If it’s under version control, it’s traceable.
Create Your First Database Publish Profile
Ok. How do I create this profile?
Step 1: Right-click the database project and choose Publish (Figure 5)
Step 2: Populate the values for your settings and click the Create button (Figure 6)
After you click Create Profile, you should see a new *.publish.xml file in your project (Figure 7).
Step 3: This step is optional but I think it’s handy. Change the “Copy to Output Directory” setting on the new *.publish.xml file to “Copy Always” (Figure 8). This ensures that when the project is compiled (via the Build command) that the publish profile is copied to the bin directory along with the *.dacpac file. This makes scripting the deploy using SqlPackage.exe easier when you’re deploying from a developer machine and MUCH easier if you’re deploying from an automated build.
I hope this is helpful and/or useful.
— Want to streamline your database and binary deployment process? Looking for suggestions on how to make all this run smoothly from Team Foundation Server’s automated build? Thinking it might be nice to get some training on how to put your insanely complex database under source control using SQL Server Database Projects? Drop us a line at email@example.com.