SSDT Schema Compare always adding objects, which are "Build = None" in Solution SSDT Schema Compare always adding objects, which are "Build = None" in Solution sql-server sql-server

SSDT Schema Compare always adding objects, which are "Build = None" in Solution


Minimal reproducible example as requested in comment:

SebTHU: Adding minimal reproducible example.

Create a new, empty sandbox database.In the database, run this script:

CREATE TABLE Table1(PersonID INT NOT NULL,FullNam nvarchar(255) NOT NULL) GO CREATE TABLE Table1_New (PersonID INT NOT NULL,FullName nvarchar(255) NOT NULL) GO CREATE VIEW vwOriginalView AS SELECT PersonID,FullNam FROM Table1 GO EXEC sp_rename 'Table1','ZZZTable1','OBJECT' GO EXEC sp_rename 'Table1_New','Table1','OBJECT' GO CREATE VIEW vwNewView AS SELECT PersonID,FullName FROM Table1 GO

This simulates an effective ALTER TABLE on Table1, but with the original table being retained as a renamed deprecated object. vwOriginalView now has an invalid reference, but we want to retain it (for the moment) as well; it would be renamed, but that's not necessary to demonstrate this problem.

In VS, create a new Database Project.Run Schema Compare against the sandbox database. Press Update to add scripts for the 4 objects into the project. Keep the comparison window open.There are now build errors (vwOriginalView has an invalid reference to column Fullnam). To ignore this object, set its BuildAction to None. The errors disappear.Press Compare on the comparison window again. vwOriginalView now appears as a "new" object in the DB, to be added to the project.This is the problem. It's nice to be reminded that, if it does exist in the project, the object's BuildAction is set to None. But with many (20-30) objects of this kind, SchemaCompare becomes confusing.

What I need is either a way for Compare to treat "BuildAction=None" objects as existing objects in the project - ideally switchable as an option, so that these objects can be made clearly visible in Compare if needed; or a way to make deprecated objects (specifically, my choice of objects) not cause build errors - an alternative to "BuildAction=None".

I've tried SQL error suppression in VS, but for one thing it doesn't work, and for another suppressing these kind of errors globally would be a bad idea.