Collisions in indirect sqlproj dependencies for separate databases

[tobymiller]

• SqlPackage or DacFx Version: 1.0.0
• .NET Framework (Windows-only) or .NET Core: any
• Environment (local platform and source/target platforms): any
• Did this occur in prior versions? I believe it worked in the old sqlproj (non-SDK) format, but never in the SDK

(DacFx/SqlPackage/SSMS/Azure Data Studio)

---

Setup

dotnet new -i Microsoft.Build.Sql.Templates

dotnet new sqlproj -n Sql1
dotnet new sqlproj -n Sql2
dotnet new sqlproj -n Sql3

update Sql2/Sql2.sqlproj adding:

<ItemGroup>
    <ProjectReference Include="..\Sql1\Sql1.sqlproj">
        <DatabaseSqlCmdVariable>Sql1</DatabaseSqlCmdVariable>
    </ProjectReference>
</ItemGroup>

update Sql3/Sql3.sqlproj adding

<ItemGroup>
    <ProjectReference Include="..\Sql2\Sql2.sqlproj">
        <DatabaseSqlCmdVariable>Sql2</DatabaseSqlCmdVariable>
    </ProjectReference>
</ItemGroup>

Create these files with the same contents: Sql1/Table1.sql, Sql2/Table1.sql, Sql3/Table1.sql

CREATE TABLE Table1 (Id INT);
GO

---

Issue demonstration

dotnet build Sql3/Sql3.sqlproj fails with:

  Sql1 succeeded (3.0s) → Sql1/bin/Debug/Sql1.dacpac
  Sql2 succeeded (1.6s) → Sql2/bin/Debug/Sql2.dacpac
  Sql3 failed with 2 error(s) (0.3s)
    /Users/toby.miller/tmp/dacfx_transitive2/Sql3/Table1.sql(1,22,1,22): Build error SQL71508: The model already has an element that has the same name dbo.Table1.Id.
    /Users/toby.miller/tmp/dacfx_transitive2/Sql3/Table1.sql(1,1,1,1): Build error SQL71508: The model already has an element that has the same name dbo.Table1.

But if you add the previously-indirect dependency as a direct dependency in Sql3/Sql3.sqlproj:

<ItemGroup>
    <ProjectReference Include="..\Sql1\Sql1.sqlproj">
        <DatabaseSqlCmdVariable>Sql1</DatabaseSqlCmdVariable>
    </ProjectReference>
</ItemGroup>

then dotnet build Sql3/Sql3.sqlproj passes.

I would expect it to pass in both cases.

---

Comment

Each sqlproj in this case is meant to represent a different database, and the ProjectReferences indicate this. Direct dependencies correctly don't encounter collisions, but indirect dependencies can encounter collisions even though they aren't intended to be in the same database as the target.

We have a workaround, which is to specify all transitive dependencies as direct dependencies in all projects, and give them their corresponding database name variables. But this is unwieldy and difficult to maintain with many database dependencies.