Collisions in indirect sqlproj dependencies for separate databases
- 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
Assessment
This issue has not been assessed yet.