< Back
Publish-Database
Post
NAME Publish-Database
SYNOPSIS
The Publish-Database CmdLet takes a dacpac which is the output from an SSDT project and publishes it to a
database. Changing the schema to match the dacpac and also to run any scripts in the dacpac (pre/post deploy
scripts)
SYNTAX
Publish-Database -DacpacPath <string> -PublishProfilePath <string> [-DacFxExtensionsPath <string>]
[-ScriptSavePath <string>] [<CommonParameters>]
DESCRIPTION
Deploying a dacpac uses the DacFx which historically needed to be installed on a machine prior to use. In 2016 the
DacFx was supplied by Microsoft as a nuget package and this uses that nuget package.
One of the main features of the DacFx is that when deploying your dacpac's you have the ability to use deployment
contributors which is awesome, however these have to be installed into the visual studio or sql server directory
under program files which people may not have access to when deploying dacpacs. This module works around that and
lets you specify the folder from where you want to load extensions.
It will also hopefully stop people from having to write the same boilerpoint code to deploy a dacpac
PARAMETERS
-DacpacPath <string>
The path to the dacpac to deploy
Required? true
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
-PublishProfilePath <string>
The path to the publish profile. A publish profile contains lots of useful info like database name and any one
of the hundreds of config options for deploying. If you do not have a publish profile use New-PublishProfile
to generate a template that you can modify
Required? true
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
-ScriptSavePath <string>
The directory where you would like to save a copy of the deployment script to. The way this works is that we
do a compare from the dacpac to the database, generate a script that will likely be used to upgrade the
database but we do a separate compare/deploy for the actual deploy. The reason is that we want tp save the
script but not run it manually. If someone edits the database between comparing and deploying then it could be
different to the actual script run
Required? false
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
-DacFxExtensionsPath <string>
Required? false
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
System.String
The path to the dacpac to deploy
System.String
The path to the publish profile. A publish profile contains lots of useful info like database name and any one
of the hundreds of config options for deploying. If you do not have a publish profile use New-PublishProfile
to generate a template that you can modify
System.String
The directory where you would like to save a copy of the deployment script to. The way this works is that we
do a compare from the dacpac to the database, generate a script that will likely be used to upgrade the
database but we do a separate compare/deploy for the actual deploy. The reason is that we want tp save the
script but not run it manually. If someone edits the database between comparing and deploying then it could be
different to the actual script run
System.String
OUTPUTS
---------- EXAMPLE 1 ----------
PS> Publish-Database -DacpacPath $DacpacPath -PublishProfilePath $PublishProfilePath
PS> Publish-Database -DacpacPath $DacpacPath -PublishProfilePath $PublishProfilePath -SaveScriptPath
$directoryToCopyDeployScript
PS> Publish-Database -DacpacPath $DacpacPath -PublishProfilePath $PublishProfilePath -DacFxExtensionPath
$semiColonSeparatedListOfPathsToFindContributors
RELATED LINKS
SYNOPSIS
The Publish-Database CmdLet takes a dacpac which is the output from an SSDT project and publishes it to a
database. Changing the schema to match the dacpac and also to run any scripts in the dacpac (pre/post deploy
scripts)
SYNTAX
Publish-Database -DacpacPath <string> -PublishProfilePath <string> [-DacFxExtensionsPath <string>]
[-ScriptSavePath <string>] [<CommonParameters>]
DESCRIPTION
Deploying a dacpac uses the DacFx which historically needed to be installed on a machine prior to use. In 2016 the
DacFx was supplied by Microsoft as a nuget package and this uses that nuget package.
One of the main features of the DacFx is that when deploying your dacpac's you have the ability to use deployment
contributors which is awesome, however these have to be installed into the visual studio or sql server directory
under program files which people may not have access to when deploying dacpacs. This module works around that and
lets you specify the folder from where you want to load extensions.
It will also hopefully stop people from having to write the same boilerpoint code to deploy a dacpac
PARAMETERS
-DacpacPath <string>
The path to the dacpac to deploy
Required? true
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
-PublishProfilePath <string>
The path to the publish profile. A publish profile contains lots of useful info like database name and any one
of the hundreds of config options for deploying. If you do not have a publish profile use New-PublishProfile
to generate a template that you can modify
Required? true
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
-ScriptSavePath <string>
The directory where you would like to save a copy of the deployment script to. The way this works is that we
do a compare from the dacpac to the database, generate a script that will likely be used to upgrade the
database but we do a separate compare/deploy for the actual deploy. The reason is that we want tp save the
script but not run it manually. If someone edits the database between comparing and deploying then it could be
different to the actual script run
Required? false
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
-DacFxExtensionsPath <string>
Required? false
Position? named
Default value
Accept pipeline input? true (ByPropertyName)
Accept wildcard characters? false
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
System.String
The path to the dacpac to deploy
System.String
The path to the publish profile. A publish profile contains lots of useful info like database name and any one
of the hundreds of config options for deploying. If you do not have a publish profile use New-PublishProfile
to generate a template that you can modify
System.String
The directory where you would like to save a copy of the deployment script to. The way this works is that we
do a compare from the dacpac to the database, generate a script that will likely be used to upgrade the
database but we do a separate compare/deploy for the actual deploy. The reason is that we want tp save the
script but not run it manually. If someone edits the database between comparing and deploying then it could be
different to the actual script run
System.String
OUTPUTS
---------- EXAMPLE 1 ----------
PS> Publish-Database -DacpacPath $DacpacPath -PublishProfilePath $PublishProfilePath
PS> Publish-Database -DacpacPath $DacpacPath -PublishProfilePath $PublishProfilePath -SaveScriptPath
$directoryToCopyDeployScript
PS> Publish-Database -DacpacPath $DacpacPath -PublishProfilePath $PublishProfilePath -DacFxExtensionPath
$semiColonSeparatedListOfPathsToFindContributors
RELATED LINKS