Project Reference Vs File Reference?

Question

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 refe

Answer 1

I've run into issues on multiple projects where file references just don't cut it. Stale references cause buku problems. Microsoft recommends that we use file references only where necessary:

http://msdn.microsoft.com/en-us/library/ee817675.aspx

Answer 2

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

This is not true for file references.

Answer 3

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

s

Answer 4

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.

Answer 5

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

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

Source

Answer 6

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.