microsoft / microsoft/DacFx

Collisions in indirect sqlproj dependencies for separate databases

Open
#608 1 comment 2 reactions 1 assignee Assigned to @Copilot View on GitHub
area: build sdk bug
Dominant language
C#
Stars
460
Forks
29
Avg merge
4d 9h
Merged PRs (30d)
7

Description

- 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:
```


Sql1

```

update `Sql3/Sql3.sqlproj` adding
```


Sql2

```

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`:
```


Sql1

```
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 `ProjectReference`s 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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.