views:

1247

answers:

8

References can be added in two ways in a project.

  1. Project Reference.
  2. File Reference.

But, When to use Project and when to use File reference?

+1  A: 

Use “project reference” to add reference to assemblies within your solution.

Use “file reference” to add a reference to a cross solution assemblies

Source

Shoban
+6  A: 

You didn't specify but I'm guessing you're referring to Visual Studio?

The main difference between a project reference and a file reference is whether or not live updates are available. In a project reference you will be able to see the effects of edits in one project immediately in the other project via items like Intellisense. So if you for instance add class named Foo, this this type will show up in intellisense immediately in any project which has a project reference on that project.

File references on the other hand can only see changes that are present on disk. A compilation must be performed and bits written to disk in order to see the changes.

In general, it's best to use a project reference.

Another angle that needs to be considered is the relative languages of the projects. Project to Project references are maximally useful if the language in both projects are the same. If the languages are different they tend to be treated more like file references than project references.

JaredPar
A: 

At the end, all references are file references, the Project Reference is just a visual studio feature, which is making a reference to a file that is being built with your solution, so whenever you build a new build, the reference is updated automatically without you going copy & paste the files

bashmohandes
A: 

A reason for me to go for a file reference (even when i have the source or created the assembly myself) is when that particular assembly does not change a lot (say once every half year). Just to shave some time of build time. Also, some projects automatically increment their version number (for instance, try to include the AjaxControlToolkit project in your solution).

Colin
I think this is scary, since it makes it pretty easy to accidentally use stale dependent library code.
Chris Farmer
+1  A: 

I just went through this...

We received, from a vendor, about 53 different VS2005 C# solution files that created 63 different project .dlls, all of which are called by a separate, commercial application.

All projects contained file references to the dlls of the other projects.

The problems with this approach were great: inter-solution dependencies were almost impossible to work out, involving a lot of "findstr" commands; the "find definition" functionality of VS would not find the source for file-referenced dlls, it would only show the definitions of the functions inside the dlls; re-building because of changes was error-prone, cumbersome, and involved opening many different solutions to re-build the entire dll set.

I spent weeks combining the 53 different solution files into one, then spent additional time changing all file dependencies to project dependencies. Now, when you "find definition" you're taken to a source file. Now, when you change a low-level project all of the dependent projects will build when you build the (one) solution.

I made a few additional changes, but the handiest was setting all of the separate projects' build directories to solutiondir/bin. That way, all dlls end up in one place.

Oh, yes: I also set 'copy local' to 'no' for all of the referenced projects' dlls. That way, each dll shows up in solutiondir/bin as the project is built and is found by the next projects to build.

The only problem we have now is that if I change a project that is used as a datasource for another project with a Windows Form then the Windows Form will not open in Designer until I re-build the project that is the datasource for the form. A small, small price to pay for all of the benefits of project references. Also, I have to build the solution upon checkout from svn because the dlls aren't in svn. In the above case the datasource .dll isn't there for Designer to find.

james
Perhaps, better use smallest solutions, and postbuild event in csproj, for copy dll and pdb in SharedLibs folder. This folder is in TFS (svn, source control).
alhambraeidos
A: 

When a project is rebuilt, all projects that project-reference it are automatically rebuild too.

This is not true for file references.

Martin Konicek
A: 

Hi

Actually both methods uses File references. The project reference is useful for VS to know when the referenced VS Project should be build

Muse VSExtensions