SSDT - Deprecated table trigger preventing publish 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 [trigger]!)

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?
There is a setting on the "drop" tab of the advanced publish settings called "Drop DML Triggers not in source."  This is checked by default, and thus triggers should be dropped by the publish process.  This is true even if "drop object in target but not in source" is unchecked.

It sounds like this has been unchecked in your publish process.  You can confirm that by looking for this element in your publish XML file (if that's how you're publishing):

&lt;DropDmlTriggersNotInSource&gt;False&lt;/DropDmlTriggersNotInSource&gt;


Removing that element, or setting it to true, should resolve your issue without setting the undesirable "drop object in target but not in source" or having to use a pre-model script.



Regarding the inciting issue:


  There is a table trigger that was removed in the past that is blocking SSDT publish preview (due to a dependency)...


If the setting I mentioned above doesn't resolve the problem, it would be helpful if you could provide a repro steps for this scenario.