"Same Database" references and post-deploy scripts

Question

Say that I have two database projects - project A and project B.  Project A references project B as a same database reference.
When deploying project A (with Include Composite Objects enabled), all of project B's objects are included, as expected.  However, project B's post-deployment script is not run.
Is this by design, or a bug?

Answer 1

Hi Jamie,
In our scenario, we are using post-deployment scripts with MERGE statements as a way to manage population of initial data in certain tables.  For example, if you imagine a fictitious Gender table:
CREATE TABLE Gender (
Id INT IDENTITY PRIMARY KEY NOT NULL,
Code VARCHAR(2) NOT NULL,
Description NVARCHAR(16) NOT NULL,
CONSTRAINT [UK_Gender_Code] UNIQUE (Code)
we would have a corresponding entry in the post-deployment script such as:
MERGE INTO Gender AS Target
USING (VALUES
('M', 'Male'),
('F', 'Female')
) AS Source (Code, Description)
ON Target.Code = Source.Code
WHEN MATCHED THEN
UPDATE SET
Target.Description = Source.Description
WHEN NOT MATCHED BY TARGET THEN
INSERT (Code, Description)
VALUES (Code, Description)
WHEN NOT MATCHED BY SOURCE THEN
DELETE;
For tables that (for better or for worse) are expected to always contain certain values, this works very well to ensure that those tables are populated with the correct entries both when databases are initially deployed and when they are updated, and also
works well to handle updating this data for new or modified entries.
But, for same-database references, the post-deploy script never runs, and you end up with empty tables.  It's possible to work around this (deploy database B to target, then deploy database A, excluding composite objects), but it doesn't really fit
nicely into the press-F5-to-deploy that SSDT's Visual Studio experience has.