I have tried to search through previously asked questions, but it is difficult to sift through them because it seems 99% refers to reference problems after a build, whereas my problem is references issues after a clean.
The problem is as follows, I am reviving an old project -which I've never worked on previously unfortunately- and everything compiles and works fine when I build the solution.
When I do a Clean Solution though, I get reference errors for one project. The project in question is a Visual Basic web service project. It has a reference to two other projects (which are C#) and when I look at the Project Properties, in the References pane I see that the Path used for the reference is SolutionFolder\Project\bin\Debug\Projectname.dll.
So whenever I clean my solution the bin\Debug is emptied and the reference is missing. Does this mean the reference is setup wrongly?
I understand from researching the issue that Project References work differently for VB projects, but I find it weird that a combination of C# and VB projects would give reference errors the moment you clean the solution.
Can anyone help me / explain why this happens?
Okay, I've created steps to recreate the issue. It works as follows:
Visual Studio -> New Project -> Visual Basic WCF Service Application
Solution -> Add -> New Project -> C# Class Library
In the class library add the following function
namespace ClassLibrary1
{
public class Class1
{
public static int Foo()
{
return 1;
}
}
}
Visual Basic WCF Project -> Add -> Reference -> C# ClassLibrary (from the Solution Project)
Build Solution
In the Service I change the GetData function as follows:
Public Function GetData(ByVal value As Integer) As String Implements IService1.GetData
Dim foo = ClassLibrary1.Class1.Foo
Return String.Format("You entered: {0}", value)
End Function
Build Solution
Now Clean Solution.
Visual Studio now tells me I have reference errors.
Build again.
Errors gone.
As Maarten stated there is an important difference between adding a project reference or adding a file reference. I'd like to explain it in more detail - original credits goes to Maarten!
There are severeal differnt ways for adding a reference to an assembly. For detailed information you may have a look at the MSDN article How to: Add or Remove References By Using the Reference Manager.
As the op asked for we focus on the file and project reference. I'll show how VS saves the reference settings and what impact they have on your project! In my example I made a solution with three projects (a, b and c). Project C refers to A and B.
As we can see a file reference statically refers to a file on your hdd. In case the file refered to is not available you will get a broken reference warning. So when you clean your solution, any assemblies already built, will be cleaned up. For this reason you do get the warning.
Refering to a project saves the project GUID of the target. So when building the current project, VS will look for the target project and build them too - if necessary.
That's why MSDN states:
You should avoid adding file references to outputs of another project in the same solution, because this tactic may cause compilation errors. Instead, use the Solution tab of the Reference Manager dialog box to create project-to-project references. This tactic makes team development easier by enabling better management of the class libraries that you create in your projects. For more information, see Troubleshooting Broken References.
EDIT
As your project contains different languages VS fails to resolve your project reference. You might have a look at this similar SO question dealing with two languages in one solution. Apparently although it is a project reference, VS handles it like a file reference.
Within Visual Studio there are several language services which are language specific. So in case you refer from one C# assembly another C# assembly the according language services will handle any potential reference errors when created by a project reference.
But in case you refer a VB.net assembly from C# (or the other way round) there is no "inter-"language service for that. A very simple example is that related <summary> tags
from a c# assembly won't show up in a VB.net project (as the linked question/comments stated).
I think that the reference is now set to the physical dll file in the bin\debug
folder instead of to the project that builds that dll file.
If you set the reference to the physical dll file, visual studio will always expect that file to be there, and otherwise it will complain.
If you set the reference to the project that builds the dll file, visual studio will look at the project, and that will always be there. Visual studio will not complain about a missing dll file since it is not interested in the dll file reference-wise.
Remove the reference that you have now, and create a new reference that points to the project instead of the dll file.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With