Emit DacFx and Database Reference Versions in Build Output

[jasonhorner]

✨ Feature Request: Output DacFx and Database Reference Versions
Is your feature request related to a problem? Please describe.

I'm always frustrated when trying to troubleshoot database builds or deployments using dotnet build or sqlpackage, and I can't easily determine which version of DacFx or database references (e.g., master.dacpac) were actually used during the process. This makes it difficult to identify version mismatches across environments or diagnose issues with builds and deployments.

Describe the solution you'd like

I would like dotnet build (when building SDK-style .sqlproj) and sqlpackage (for deployment or script generation) to include the following in the standard output:

The version of Microsoft.SqlServer.DacFx being used (e.g., 170.0.94.3)
Possibly the version of Microsoft.Build.Sql

The versions of any referenced DACPACs (e.g., Microsoft.SqlServer.Dacpacs.Azure.Master v160.2.4)

This information could be printed by default or behind an optional verbosity flag (/v:normal or /v:detailed), and would dramatically improve traceability and troubleshooting.

Example:

DacFx version: 170.0.94.3
Reference: Microsoft.SqlServer.Dacpacs.Azure.Master v160.2.4

Describe alternatives you've considered

Note sure how else to get this information open to suggestions
I would expect this to end up in one of the build artifacts but wasn't able to find it

Additional context
This would be especially helpful in DevOps pipelines or Fabric deployments where validation of toolchain versions is critical. It would also help differentiate between breaking changes caused by SDK upgrades versus other deployment logic.

[ErikEJ]

@jasonhorner I will add this proposal to our MsBuild.Sdk:SqlProj project!

btw - sqlpackage already has a "version"

[jasonhorner]

@ErikEJ yes

sqlpackage.exe /version

outputs the version however when you run a sqlpackage command such as

sqlpackage /Action:Script

There doesn't appear to be a way to determine the version that was called. This is probably a more minor issue. but useful as I struggled after I had updated sqlpackage (DacFx) locally. The script generated by the SQL project extension (via Publish → Generate Script) differed from the one produced by running sqlpackage from the command line. Being able to easily verify the DacFx version in use would have saved time and reduced confusion.

[ErikEJ]

Maybe a version number in the script would be more useful? The VS DacFX version used in very well hidden.

[jasonhorner]

Perhaps, to be honest it's all a bit confusing to figure out how it all fits together and figure out if the issue is in the sqlproject extension, SqlPackage or build.sql or the underlying DacfX.. Every time I dig in it makes a bit more sense.