In database Project Not able to resolve Circular References
In Database Project Not able to resolve circular reference. Still it is issue in VS. Also if we add more than 10 Project in a single database Solution then its goes as killing slow.
Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.
- The Visual Studio Team
Manuel Rebello de Andrade commented
How to solve this in many scenarios: you can have multiple projects for a single database.
1. Create all non-referencing objects within DB X, in a base project (Db_X.sqlproj), which does not have any references to other Dbs.
2. Create an "extension" project for DB X (Db_X.Ext.sqlproj), which also adds objects to DB X, and references other DBs - for instance DB Y.
If you follow this pattern for all DBs you will only have problems if objects referencing others in external DBs are also referenced from those DBs.
In our situation, we create a commercial application using a database project. We have a standard shared core set of tables and procs; and a client-bespoke part. We use a DACPAC of the standard part as a database reference in a database project and then add additional bespoke tables and procs as necessary. Some of these tables are of nesscity referered to from the standard part, even if only as SELECT *. This results in numerous SQL71502 warnings, which we are unable to fix. Ideally, we could generate either stubs for the bespoke tables known to exist - with a property other than build so that warnings are resolved but the bespoke tables are not included in a built DACPAC, or we could include a DACPAC of a template client project in our standard project so that the warnings go away.
Erik Ciccarone commented
Agreed, It is very common practice to create Views within a DB to point to tables/views in other DBs on the same server to avoid having DB Names scattered throughout your SP code. Then creating a solution that contains all the DBs to organize your DB code for source control can easily create the circular reference occurances between the DBs. If you are serious about letting developers manage DB Projects in Visual Studio, there needs to be a way to configure/disable the blocking created with this error condition.
Madhu Addepalli commented
It is time that something is done to support circular references between database projects. We recognize that having circular dependencies between databases is not ideal. However SQL server allows it and Visual Studio DB projects throws an error when we try to add a circular reference between two DB projects in the same solution. This is a bigger problem when there is a DB view requiring the reference as it result in SQL03006 errror causing the build to fail making the solution unusable.
Overcoming this limitation is crucial to make DB projects a viable option for database source control in the long term.
The various workarounds suggested in MSDN forums far are far from ideal:
1) Creating a third DB project and include objects that require circular reference
2) Manage references using static .dbschema file