Without VS 2026 tooling for new SDK-style sqlproj and VS 2022 tooling still being preview and incompatible with legacy SSDT, I am left with having to maintain some legacy old-sqlproj projects.

I want to be able to built those deterministically (same DacFx version) both locally and on buildserver, and also enforce some lock-step versioning with sqlpackage.

Unfortunately, research efforts so far have been rather unfruitful:

• Microsoft.Data.Tools.Msbuild looked promising but it hasn't been updated since 2020, and I'd like to get into the new DacFx/sqlpackage versions 162+

• Alter DacFx used by SQL Server Data Tools (SSDT) doc says that it's possible to replace some of the DLLs in the SSDT installation for VS 2022 with the ones from the DacFx nuget but that sounds very fragile and not easily to replicate across other devs's environments + build servers.

My least painful possible options seems to be to pin a version of DacFx (similar to the Microsoft.Data.Tools.Msbuild old way) in a tools folder in the repo and maybe leverage the SQLDBExtensionsRefPath env variable/msbuild property as described in answers under this question. But even here I am a bit unsure I can replicate reliably the packaging just from DacFx's nuget as close to as the deprecated Microsoft.Data.Tools.Msbuild.

Is there a way to maintain deterministic builds for non-SDK sqlproj in 2026?