\nAt my DAC talk at TechEd last week, the thing that seemed to cause the most interest was the PowerShell scripts to use DACPACs\/BACPACs. I thought I'd post that here, along a question about cmdlets in general. Using PowerShell against the library allows admins to use all of the functionality that's in SSMS, with the options available in SqlPackage (think DacOptions object) and more (like BACPACs)… The premise is that administrators (DBAs or others) might want to integrate this functionality as part of their deployment into a PowerShell script.\n<\/p>\n
\nPowerShell doesn't officially support .NET 4.0 assemblies until PowerShell 3.0, so you'll need a config file. You'd name this PowerShell.exe.config and place it in the same directory as the PowerShell.exe:\n<\/p>\n
\n<?xml version="1.0"?>
\n<configuration>
\n <startup useLegacyV2RuntimeActivationPolicy="true">
\n <supportedRuntime version="v4.0.30319"\/>
\n <supportedRuntime version="v2.0.50727"\/>
\n <\/startup>
\n<\/configuration>\n<\/p>\n
\nThen the scripts. Granted, I'm using the defaults, not the DacOptions or list of tables to export.\n<\/p>\n
\n# load in DAC DLL (requires config file to support .NET 4.0)
\n# change file location for a 32-bit OS
\nadd-type -path "C:\\Program Files (x86)\\Microsoft SQL Server\\110\\DAC\\bin\\Microsoft.SqlServer.Dac.dll"\n<\/p>\n
\n# make DacServices object, needs a connection string
\n$d = new-object Microsoft.SqlServer.Dac.DacServices "server=."\n<\/p>\n
\n# register events, if you want 'em
\nregister-objectevent -in $d -eventname Message -source "msg" -action { out-host -in $Event.SourceArgs[1].Message.Message }\n<\/p>\n
\n# Extract DACPAC from database
\n# Extract pubs database to a file using DAC application name pubs, version 1.2.3.4
\n$d.extract("c:\\temp\\pubs.dacpac", "pubs", "pubs", "1.2.3.4")\n<\/p>\n
\n# Export schema and data from database pubsdac
\n$d.exportbacpac("c:\\temp\\pubsdac.bacpac", "pubsdac")\n<\/p>\n
\n# Load dacpac from file & deploy to database named pubsnew
\n$dp = [Microsoft.SqlServer.Dac.DacPackage]::Load("c:\\temp\\pubs.dacpac")
\n$d.deploy($dp, "pubsnew")\n<\/p>\n
\n# Load bacpac from file & import to database named pubsdac2
\n$bp = [Microsoft.SqlServer.Dac.BacPackage]::Load("c:\\temp\\pubsdac.bacpac")
\n$d.importbacpac($bp, "pubsdac2")\n<\/p>\n
\n# clean up event
\nunregister-event -source "msg"\n<\/p>\n
\n
\nNow, the question for the reader. There has been a lot of work going on to make sets of APIs into libraries of cmdlets. I thought about this, but it seemed to be such a simple API that I'd be writing a cmdlet encapsulating 2-3 lines of code each time. So when is it useful to "cmdlet-ize" APIs? Always? Or is it too much to cmdlet-ize for every two lines of code? How about 5 lines of code? Is there a cutoff? Let me know on Twitter or in comments…\n<\/p>\n
\nThanks to those of you who attended the session.\n<\/p>\n
\n@bobbeauch<\/p>\n","protected":false},"excerpt":{"rendered":"
At my DAC talk at TechEd last week, the thing that seemed to cause the most interest was the PowerShell scripts to use DACPACs\/BACPACs. I thought I'd post that here, along a question about cmdlets in general. Using PowerShell against the library allows admins to use all of the functionality that's in SSMS, with the […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,21],"tags":[],"class_list":["post-486","post","type-post","status-publish","format-standard","hentry","category-data-tier-applications-dac","category-powershell"],"yoast_head":"\n