v2.9.1

What's Changed

• Fix #615 by @ErikEJ in #638

Full Changelog: v2.9.0...v2.9.1

v2.9.0

Use Nuget based code analyzers

In this release we have added support for NuGet based code analyzers, simply add a reference to a rules Nuget package in your project file:

<ItemGroup>
    <PackageReference Include="ErikEJ.DacFX.SqlServer.Rules" Version="1.1.0" />
    <PackageReference Include="ErikEJ.DacFX.TSQLSmellSCA" Version="1.1.0" />
</ItemGroup>

Notice that you should set your target framework to netstandard2.1 if you consume NuGet based rules!

<TargetFramework>netstandard2.1</TargetFramework>

• Report DacModelExceptions better, and continue processing all files by @ErikEJ in #598
• Verify that GenerateCreateScript works by @ErikEJ in #599
• Enable .NET Analyzers in DacpacTool by @ErikEJ in #604
• Support NuGet based code analyzers by @ErikEJ in #625

Full Changelog: v2.6.0...v2.9.0

Bring your own rules

We've now added the ability to "bring your own rules" for the new code analysis feature introduced in 2.7.0. Please see our updated docs for more details. Thanks to @ErikEJ for the contribution.

In this release we've also included some bug fixes.

Introducing code analysis

Starting with release 2.7.0 we now have the ability to run code analysis rules on your SQL projects. Out of the box we support the following rules:

• Microsoft.Rules (1, 2 and 3 )
• SqlServer.Rules
• Smells

At this time we do not have the ability to add custom rules, but if you feel this is important please don't hesitate to file an issue. Make sure you read through our docs on this new feature.

Thanks to @ErikEJ for his contribution on this feature.

Escape SQLCMD parameter values

We've fixed a small issue (#458) that caused a build error if a SQLCMD parameter's value had spaces in them. Thanks to @Aaronontheweb for reporting this issue.

Full Changelog: v2.6.0...v2.6.1

.NET 8 support

In this release we've added support for .NET 8, which is currently in preview. Note that we've also dropped our support for .NET Core 3.1 in this release as that is no longer supported by Microsoft. If you're still using .NET Core 3.1 we recommend you stay on an older version of MSBuild.Sdk.SqlProj.

As part of this release we've also updated some of our third-party dependencies and we've introduced a capability in the SDK that will allow Visual Studio extensions to check if a project is using this SDK.

Please see all changes below:

What's Changed

• Bump Microsoft.SqlServer.SqlManagementObjects from 170.11.0 to 170.13.0 by @dependabot in #393
• Bump Microsoft.SqlServer.DacFx from 161.6374.0 to 161.8089.0 by @dependabot in #399
• Bump Microsoft.NET.Test.Sdk from 17.4.1 to 17.5.0 by @dependabot in #401
• Add Capability to enable check via Visual Studio SDK by @ErikEJ in #406
• Remove support for .NET Core 3.1 by @ErikEJ in #408
• Call out NS2.0 dependency in README by @IanKemp in #411
• Try .NET 8 support by @ErikEJ in #413
• Bump Shouldly from 4.1.0 to 4.2.0 by @dependabot in #416
• Bump Shouldly from 4.2.0 to 4.2.1 by @dependabot in #418
• Bump Nerdbank.GitVersioning from 3.5.119 to 3.6.128 by @dependabot in #421
• Bump Nerdbank.GitVersioning from 3.6.128 to 3.6.132 by @dependabot in #424
• Bump Microsoft.SqlServer.DacFx from 161.8089.0 to 162.0.52 by @dependabot in #425

New Contributors

• @IanKemp made their first contribution in #411

Full Changelog: v2.5.0...v2.6.0

Allow overriding dacpac filename for a package reference

Up until version 2.5.0 MSBuild.Sdk.SqlProj has assumed that the name of the .dacpac file in a PackageReference is the same as the ID of the package being referenced. Although this is the case in many scenarios, there are scenarios where a referenced package might contain multiple .dacpac's or the filenames might not be the same. Therefore we now support specifying a DacpacName attribute on a PackageReference that allows for overriding the name of the .dacpac being referenced from that package.

This is especially useful for referencing the new Microsoft.SqlServer.Dacpacs packages released by Microsoft, which contain the definitions of the master and msdb databases.

Default values for SQLCMD variables

In this release we've made sure that any default values configured in the MSBuild.Sdk.SqlProj project are also embedded in the resulting .dacpac so that they may be used during deployment. Thanks to @Geims83 for his contribution.

SQL Server 2022 support

Starting with version 2.3.0 we now support targeting SQL Server 2022 with MSBuild.Sdk.SqlProj. Thanks to @ErikEJ for his contribution.

Note: In this release we've made a change so that when using dotnet publish to deploy your project to a development SQL Server we're not using an encrypted connection by default (ie. the connection string's Encrypt property is set to False). As development SQL Servers typically don't have a TLS certificate and our dotnet publish support is targeted at development scenario's we feel that this is a good default. For production deployments we recommend using the sqlpackage tool, which fully supports encrypted connections.

Support for .NET 7

With version 2.2.0 we now support building using the .NET 7 SDK. Thanks to @ErikEJ for his contribution.

Please note that with this release we've also dropped support for .NET 5 as it is no longer supported by Microsoft. If you're still using .NET 5 we recommend you keep using your current version of MSBuild.Sdk.SqlProj until you're ready to upgrade to .NET 6 or 7.