Deployment results in non-clustered index being rebuilt on table with partitioned index

[zijchen]

When a table has a partitioned index and a non-clustered index, deploying the dacpac without any changes still result in the non-clustered index being rebuilt.

Repro by creating a sqlproj with this script:

ALTER DATABASE [$(DatabaseName)]
  ADD FILEGROUP [Negative];
GO

ALTER DATABASE [$(DatabaseName)]
  ADD FILEGROUP [Zero];
GO

ALTER DATABASE [$(DatabaseName)]
  ADD FILEGROUP [Positive];
GO

CREATE PARTITION FUNCTION [PartitionFunctionBySign](INT)
  AS RANGE
  FOR VALUES (0, 1);
GO

CREATE PARTITION SCHEME [SignedPartitions]
  AS PARTITION [PartitionFunctionBySign]
  TO ([Negative], [Zero], [Positive]);
GO

CREATE TABLE [dbo].[Table1]
(
  [Id] INT NOT NULL,
  [Quantity] INT NOT NULL,
  [Quantity2] INT NOT NULL,
    CONSTRAINT [PK_Table1] PRIMARY KEY 
        CLUSTERED ([Id], [Quantity])
        ON [SignedPartitions] ([Quantity])
);
GO

CREATE NONCLUSTERED INDEX IX_Table1
  ON [dbo].[Table1] ([Quantity2])
  WITH (DATA_COMPRESSION = ROW);
GO

Deploying the same dacpac a second time without any changes, sqlpackage will still generate a script to rebuild the non-clustered index. Deployment is successful however it adds an unnecessary step and is problematic for large tables.

PRINT N'Altering SqlIndex [dbo].[Table1].[IX_Table1]...';


GO
ALTER INDEX [IX_Table1]
    ON [dbo].[Table1] REBUILD WITH(DATA_COMPRESSION = ROW);


GO

I suspect the bug lies within the Reverse Engineering logic as the extracted dacpac has some differences to the original dacpac built from sqlproj.