Vis studio 2017 not always honoring database references

Question

0.00/5 (No votes)

See more:

Using VS2017 on Win Server 2016

I have a database solution with about a dozen projects, representing different databases on the db server. Some of these projects depend on some of the other projects. There are no circular references in the solution.

On one of the projects, the build process reports unresolved reference errors in both of the dependency projects it references, almost as if it does not see the dependency projects at all.

When I look at the references in the solution explorer, there is no indication that there is any problem with the reference itself (no yield sign indicating it can't find the specified project), and each of the dependency projects that are referenced build without a problem.

There are other projects in the solution that use at least one of the same dependency projects, and they build without error.

Does anyone know why this could be happening?

What I have tried:

I tried removing and re-adding the references, suppressing the reference warnings, shutting vs2017 and restarting, turning off the code analysis stuff, clean/rebuild, and nothing has worked.

Posted 3-May-21 4:04am

#realJSOP

Updated 3-May-21 23:50pm

Add a Solution

Comments

[no name] 3-May-21 14:37pm

Insure in "Build | Configuration Manager" that everything that needs to be built is checked. Sometimes I rebuild dependencies explicitly (just for the halibut) before doing a key deploy. (In case it's a build order thing).

#realJSOP 4-May-21 5:05am

Been there, done that. I figured out what was wrong, but still don't know why it caused problems. I'm going to add a "solution that explains it.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

#realJSOP · Answer 1 · 2021-05-03T23:50:00

So I figured out what was causing the issue, but I don't know WHY it was causing the issue. Before I start, I have to tell you that I've been using Visual Studio since it was first invented back in the 90's, and this is the first job I've ever had where database projects were even used, so this is very new territory for me.

Setup:

0) I have a database solution that contains 12 database projects. All of them are configured for SQL Server 2016, and are configured identically as far as project properties are concerned (with the obvious exceptions of things like output filenames are concerned).

1) All of the outputted files from the build process in all projects go into a common "Schemas" folder, and all of the projects have identical post-build events that copy the dacpac files to yet another folder (don't ask, this wasn't my choice, it's merely "the way we do it").

2) Some of the projects have no dependencies (these build fine), some of them have two dependencies (these build fine), and one of them has three dependencies (this is the one that wasn't building). One of the project dependencies is used by many of the other projects, and one is used by the project that wouldn't build. BOTH of those dependency projects compiled without issue.

3) One of the dependencies is master.dacpac that ships with Visual Studio. The other two possible dependencies are projects within the solution, and the references are to the actual projects, and not the compiled dacpacs that they generate.

4) When I added the references to the projects, I added a database reference, selected the appropriate project, and clicked OK, leaving all of the default settings. Each time I added the necessary references to one of the projects, I built the entire solution. It always built successfully (lots of warnings, but no errors) until I got to the last project that had three references.

5) The last project refused to build, even though all of the dependency projects it reference built just fine. The build attempt would generate "unreferenced" errors, everywhere that the project would try to use a table, view, or stored proc from the referenced database.

6) The fix was to remove/re-add the project references, but to delete the SQL variable name ( "($dbname)" ) that was being created by the Visual Studio Add Database reference wizard. When I did that, I did a clean/rebuild and everything built fine.

7) Why was that one project different. All of the other projects that used the same referenced project built successfully. Given that all of the projects' settings were the same, and ALL of the other projects built without issue, I'm baffled as to why I had to fix it the way I had to.

Note - the warnings are all because we fully qualify our database component names when we do select/insert/delete/merge statements, and for whatever reason, Visual Studio doesn't like that. We even tried putting the square brackets around the parts of the component name, and that didn't fix it. The only thing that fixed it was going from this:

select * from database.schema.table

to this:

select * from schema.table

I call it the "self-referencing bug", because it's perfectly valid in SQL server to do a fully qualified reference like that, but Visual Studio refuses to accept it, and I haven't found a way to turn the warning off. Even doing compiler directives in the properties doesn't do it.