RobRolls gives a decent summary, and I wrote this message yesterday, so my apologies if it repeats some of what he said; in the process of writing it I realised I'd make a small mistake in my code, and I wanted to fix that first. I also took the opportunity to merge the upstream changes, so the fork is pretty up-to-date now.
A .dacpac file is the output of an SSDT project, similar to a .dll; it's essentially a compiled version of the database project. It can then be "installed" into an SQL Server instance, or have a number of other things done with it (e.g. incremental updates to database schemas).
SSDT projects can reference other .dacpac files, which gives access to their tables, stored procedures, and so on. They can also reference .dll assemblies, which allows the SQL Server instance to perform tasks that .NET code can do, but is difficult or impossible in T-SQL. For this reason, SSDT projects are able to reference .dacpac files, and also .dll assemblies.
There is however a major difference between referencing DACPACs and DLLs: when adding a reference to a DACPAC, the user is given the option to include it as a part of the current database, as a different database on the same server, or on a different server entirely. For now, in my code, I have simply ignored this issue, and add database references in the default way, which is as part of the same database. If this is not what users need / want / expect, I'll have to find some way to change this.
There are also a couple of "standard" databases that are analogous to GAC references; these are added from the GUI in a slightly different way, but the API seems to treat them normally, so that doesn't seem to be a problem.
I hope that answers your questions, and gives a little bit of background on SSDT. :-)
Thanks and best wishes,
Tom
A .dacpac file is the output of an SSDT project, similar to a .dll; it's essentially a compiled version of the database project. It can then be "installed" into an SQL Server instance, or have a number of other things done with it (e.g. incremental updates to database schemas).
SSDT projects can reference other .dacpac files, which gives access to their tables, stored procedures, and so on. They can also reference .dll assemblies, which allows the SQL Server instance to perform tasks that .NET code can do, but is difficult or impossible in T-SQL. For this reason, SSDT projects are able to reference .dacpac files, and also .dll assemblies.
There is however a major difference between referencing DACPACs and DLLs: when adding a reference to a DACPAC, the user is given the option to include it as a part of the current database, as a different database on the same server, or on a different server entirely. For now, in my code, I have simply ignored this issue, and add database references in the default way, which is as part of the same database. If this is not what users need / want / expect, I'll have to find some way to change this.
There are also a couple of "standard" databases that are analogous to GAC references; these are added from the GUI in a slightly different way, but the API seems to treat them normally, so that doesn't seem to be a problem.
I hope that answers your questions, and gives a little bit of background on SSDT. :-)
Thanks and best wishes,
Tom