Support for project references

We now support project references, meaning you can add a project reference from one project to another and use the objects defined in both projects. This works without the need to package the referenced project into a NuGet package first. Please refer to the README for more details on how to add a project reference.

In this release we've also included a couple quality of life improvements. For example, we now properly support Visual Studio's fast up-to-date-check which should improve build times if you're working in Visual Studio. We've also improved the output for the publish command which should make it easier to diagnose issues when publishing your database to a SQL Server. Finally we've made it easier to specify a different name for the .dacpac file. This can now be controlled by setting the <TargetName> property in the project file and dotnet publish continues to work after setting it.

Support for merging pre- and postdeployment scripts

This release adds support for merging the pre- and postdeployment scripts that are specified as the '<PreDeploy> or '<PostDeploy> items in the project file. Previously any other scripts included from the referenced scripts would not be picked up and be part of the resulting .dacpac. Now all the included scripts are merged into the main pre- or postdeployment script before being packaged into the .dacpac. This fixes #23 which has been one of our most requested features.

Thanks to @jeffrosenberg for working on this feature.

Improved error reporting

With version 1.7.0 we have improved the error and warning reporting being done by this package. In previous versions errors and warnings would be visible in the Error List in Visual Studio. However no source information for the error or warning would be provided which meant you would need to do some digging to figure out where the error or warning was coming from. Now we provide full traceability to the source file including line number and column of where the error occurs. This makes it easier to fix errors and warnings in your projects.

In this release we've also added new item templates for creating User-Defined Data and Table types. You can now also specify a schema name when you create new items from the command line using -s <schema-name> as an argument for the dotnet new command. Finally we've also fixed an issue in the incremental build support that we've added back in 1.3.0 where a new build would not be triggered if a pre- or postdeploy script nor the RefactorLog was modified.

Thanks to @ErikEJ and @jeffrosenberg for their contributions in this release.

Support for large projects

For some larger projects users could run into an issue, especially on Windows, where the command line tool being run by the SDK to perform the actual packaging would fail because the command line arguments list would be too long. This has now been resolved by writing the list of files that are included in the project to a text file, which is then picked up by the command line tool.

Thanks to @jeffrosenberg for this contribution.

External databases and .NET 5.0 support

This releases adds support for using a PackageReference as an external database. This is useful if you want to make use of database objects that are defined in another database, for example the master database. This is achieved by adding the DatabaseVariableLiteralValue item metadata to the package reference and setting it to the name of the external database. You can then use objects from the referenced .dacpac using the [<database-variable-literal-value>].[<schema>].[<object>] syntax within your project.

Additionally we now support building projects leveraging MSBuild.Sdk.SqlProj with the .NET 5.0 preview SDK's. Previously if you had the preview SDK installed you would encounter the error message The current SDK bundles target framework 'netcoreapp5.0)' which is not supported by MSBuild.Sdk.SqlProj. Either install a .NET Core SDK that supports 2.1 or 3.1, or file an issue at https://github.com/jmezach/MSBuild.Sdk.SqlProj/ to add support.. This could be resolved by adding a global.json pinning your SDK version to either 2.1 or 3.1. Now the error should no longer appear if you have the 5.0 preview SDK installed.

Bugfix

This releases fixes bug #50. On Windows builds would fail if the username of the current user contains a space. This has now been fixed.

RefactorLog support

The original SQL Server Database Projects maintain a log of refactorings performed in the database project. These are stored in a .refactorlog file. In previous versions of MSBuild.Sdk.SqlProj these weren't embedded in the resulting .dacpac. Now we embed this file into the package if it is defined in the .csproj using the following syntax:

<Project Sdk="MSBuild.Sdk.SqlProj/1.5.0">
  ...
  <ItemGroup>
    <RefactorLog Include="TestProject.refactorlog" />
  </ItemGroup>
  ...
</Project>

Template pack

Starting with 1.4.0 we are now also shipping a set of templates that can be used with dotnet new. These ship as a separate NuGet package that can be installed using dotnet new --install MSBuild.Sdk.SqlProj.Templates. After that you can create new projects using dotnet new sqlproj. We've also included item templates for some of the most common SQL object types such as Tables, Views, Stored Procedures and Functions. If you feel a particular object type is missing please don't hesitate to file an issue or submit a PR. Eventually these templates will also start showing up in Visual Studio. This feature is currently in preview and we've already identified an issue that the Visual Studio team will be looking into.

Note that the version of the templates is updated in lock-step with the main package itself, meaning that when a new version of MSBuild.Sdk.SqlProj ships a new version of MSBuild.Sdk.SqlProj.Templates is also shipping and the template will reference the new version of MSBuild.Sdk.SqlProj. You can update your installed version of the templates using dotnet new --update-apply. Although we've also shipped a new version of MSBuild.Sdk.SqlProj with this release no changes have been made to its functionality. We've merely added the templates.

Floating versions and incremental build support

Version 1.3.0 introduces support for floating versions for PackageReferences allowing you to specify a version like1.3.* for a package reference and it will resolve to the latest 1.3 version of the specified package available. Thanks to @jeffrosenberg for his contribution on this.

This version also adds incremental build support meaning which should speed up repeated builds. As long as the source files (*.sql) and the project file (.csproj) have the same or an older last modified date as the .dacpac the .dacpac will not be build again. This saves the time needed to rebuild the package. Thanks to @jvilimek for his contribution.

Adding publishing support

MSBuild.Sdk.SqlProj 1.2.0 introduces support for publishing a project to a local SQL Server instance. On Windows running dotnet publish should work out-of-the-box if you have a default SQL Server instance installed on your machine. On Mac and Linux we cannot use Windows authentication, so you'll need to specify a username and password. Checkout the README for more details on how publishing works and how you can customize the process to suit your needs.

IMPORTANT: With this release we've dropped support for .NET Core 2.2 since that version is end-of-life. You should upgrade your projects to .NET Core 3.1.