Provide an official tSQLt .dacpac as a NuGet package

[nealmummau]

Background
tSQLt today distributes a set of compiled .dacpac files—e.g. tSQLt.2019.dacpac, tSQLt.2017.dacpac, etc.—but no official NuGet feed. The MSBuild.Sdk.SqlProj documentation describes how you can reference a .dacpac from a NuGet package in your .csproj by using the DacpacName metadata. Without an official package on NuGet.org, teams must roll their own .nuspec and private feed just to pull in the right tSQLt version.

Without a NuGet package, teams using MSBuild.Sdk.SqlProj must create and maintain their own .nuspec and private package feed just to reference tSQLt in their database projects.

Proposal
Publish one NuGet package per SQL Server version, each containing exactly one .dacpac. For example:

• tSQLt.Sql2019.Dacpac → contains tSQLt.2019.dacpac
• tSQLt.Sql2017.Dacpac → contains tSQLt.2017.dacpac
• …and so on for each supported version.

Example Usage
A project targeting SQL 2019 would reference

<Project Sdk="MSBuild.Sdk.SqlProj/3.1.0">
  <PropertyGroup>
    <TargetFramework>netstandard2.1</TargetFramework>
    <!-- 150 = SQL Server 2019 -->
    <SqlServerVersion>150</SqlServerVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference
      Include="tSQLt.Sql2019.Dacpac"
      Version="1.0.0" <!-- bump as new tSQLt versions are released -->
      DacpacName="tSQLt"
      DatabaseVariableLiteralValue="tSQLt" />
  </ItemGroup>
</Project>

For SQL 2017:

<PackageReference
  Include="tSQLt.Sql2017.Dacpac"
  Version="1.0.0"
  DacpacName="tSQLt"
  DatabaseVariableLiteralValue="tSQLt" />

Benefits

• Minimal footprint: only the single .dacpac you need is restored.
• Familiar model: mirrors Microsoft’s Microsoft.SqlServer.Dacpacs.* approach.
• Clear versioning: package version aligns with tSQLt framework releases.

Request
Could you please publish tSQLt.Sql2019.Dacpac, tSQLt.Sql2017.Dacpac, etc., to NuGet.org? Having an official, per-version package will streamline adoption in MSBuild.Sdk.SqlProj–based database projects. Thank you!