There is a table trigger that was removed in the past that is blocking SSDT publish preview:
This deployment may encounter errors during execution because changes to [table] are blocked by [trigger]'s dependency in the target database.
but in order to remove it from the database it must either be manually dropped (since the publish preview is failing so not even predeploy scripts get run), or the option "drop objects in target not in source" must be enabled.
[trigger] is on a different table than
[table]. The table containing
[trigger] is having a column removed and
[table] is having a column added. Neither column is even referenced by
We cannot enable this advanced publish setting in general because of other migration scripts that exist in the postdeploy section that rely on deprecated objects, and we cannot have our integration team use this option either because it risks data loss on PROD. But we like to use this option periodically to (manually) test for leftover references to objects that were removed, because the build does not throw errors about them due to deferred name resolution (which presumably exists to enable what I consider a pungent code smell to create non-temporary objects at runtime), as the error can go unnoticed otherwise until a newer system that never had the object introduced is finally tested.
How is this situation fully resolved without pre-model scripting?