References are always created not between projects but between assemblies:
http://msdn.microsoft.com/en-us/library/hk5f40ct%28v=vs.90%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=vs.110%29.aspx[
^].
Nevertheless, under Visual Studio you can reference one project by another one. In Solution Explorer, use "Add Reference", and, in the "Add Reference" window, click the tab "Projects". What it gives your?
Essentially, this is nothing more than some automation of development at the level of a
Solution which allows you to avoid direct referencing of assemblies, but their executable modules (usually, .DLL files, but it can be anything else, even .EXE). You can use
strongly named assemblies (highly recommended), and later change the assembly signatures, version or location of the assembly (output path, at the project level). All this changes may make a reference to the assembly invalid. Referencing of the projects resolves it. No matter what you do with the project to be references, the reference to it essentially tells the MSBuild: "reference whatever assembly that project produces on output". In this approach, you can boldly apply any changes to assemblies, they will be correctly found and referenced through the information kept by the project files. Convenient, right?
But as far runtime is concerned, an assembly references other assemblies, not projects. From the perspective of runtime, "projects" do not exist.
—SA