Improved error handling

In this release we've improved the error handling for pre-/post-deployment scripts in case they cannot be parsed. You should now be able to quickly find out which file cannot be parsed, which is especially important when including files through the :r <file>.sql syntax.

Thanks to @jeffrosenberg for his contribution.

Bugfixes and dependency updates

This releases incorporates a bug fix for the generate script in 1.15.0 where the generated script wasn't being properly copied to the output folder. We've also updated some of our dependencies to their latest versions to increase security and stability.

Support for generating scripts

We now have the ability to generate a script to create the entire database at build-time. This is similar in functionality to what SQL Server projects offered. No comparison will be made with a target database, just a script for creating all the objects defined within the project. It can be enabled by adding <GenerateCreateScript>True</GenerateCreateScript> to the project file.

Thanks to @markalroberts for his contribution on this feature.

Reference other projects/packages using SQLCMD variables

In this release we've added support for using SQLCMD variables to reference objects defined in references defined by <ProjectReference> or <PackageReference>. This is achieved through the DatabaseSqlCmdVariable and/or ServerSqlCmdVariable item metadata on the reference. Please refer to the README for more details on how to use this feature.

Thanks to @McHarny for his contribution.

Suppress warnings in individual files

In addition to suppressing warnings at the project level, that we've added in 1.12.0, we now also support suppressing warnings for individual files in your project. Thanks again to @McHarny for his contribution on this feature.

Treat warnings as errors support

In version 1.12.0 we've added support for treating warnings as errors. This can be enabled both by setting TreatTSqlWarningsAsErrors (as is common in the old .sqlproj format) as well as TreatWarningsAsErrors (which is common in regular C# projects). Specific warnings can also be excluded from this by using SuppressTSqlWarnings with a semi-colon or comma separated list of warning codes. Refer to the README for more details on this feature.

Thanks to @McHarny for his contribution on this feature.

Bug fix for project references

In this release we've fixed a bug with project references. When an MSBuild.Sdk.SqlProj references another MSBuild.Sdk.SqlProj project the .dacpac from the referenced project was being processed as a .NET assembly. In certain situations this would lead to build errors. We now explicitly remove the .dacpac's from the set of referenced assemblies to avoid this, since they are not assemblies in the first place.

Fix support for complex deployment options

As described in the README there are a couple of complex deployment options such as DatabaseSpecification, ExcludeObjectTypes and DoNotDropObjectTypes. Previously these had to be specified using semi-colon separators. Unfortunately this turned out not to work at all due to how semi-colons are treated by shells. With this release we've modified this to use comma separators instead.

Allow running pre-/post-deployment scripts for dependencies

By default when adding a PackageReference or ProjectReference to another project the pre- and post-deployment scripts of those dependencies are not run during a dotnet publish. With version 1.11.0 we've added an opt-in feature to enable this by adding a property named RunScriptsFromReferences with a value of True to the project file.

Please note that if any of those scripts rely on non-default SQLCMD variables you will have to include those into your project file as well. There currently is no check to make sure that these have been specified. Feel free to open an issue if you feel this is important.

Support for alternate SQL Server port

In this release we've added support for specifying an alternate port when publishing a .dacpac to a SQL Server instance. This could be done already with previous versions but we didn't quite like the experience. Now you can specify the TargetPort property in either the project file or from the command line. If left unspecified we'll assume the default SQL Server port.

Thanks to @jeffrosenberg for this contribution.