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

utils references:

http://www.lostechies.com/blogs/chad_myers/archive/2008/07/15/project-anti-pattern-many-projects-in-a-visual-studio-solution-file.aspx

http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterLargedotNETProjects.aspx

http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Answer 2

One error (C1083) I had when switching to references (& removing relative includes) was "Header not found." I had:

• in preferences include directory: ../../src/module
• in source code: #include "file.h"

---

Fix the relative path for it to work:

#include "module/file.h"

Answer 3

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).

Answer 4

I've specifically set our development team on using File references rather than project referecnes in the majority of cases: We operate in a high integrity domain. So each component that is not directly part of this work (i.e. stuff that is shared across other projects) should not be changed willy nilly. So the idea is (in an ideal, non-greenfield work) that we take tested, authorised, known versions of the sub components from a release area on the network and include them in a components area of the solution.

This is intended to simplify maintenence and testing as it should avoid many similar versions proliferating, all with different build or SVN numbers.

The second reason (and is probably my C/C++ background) is that I like to know I am using all Debug or all Release versions. You can't do this easily in .NET projects. We build out to a components\$configuration$ directory and then have a post-build step to copy from components\$configuration$ to the directory above. All file references are to the files in the component directory only meaning (I believe) that we truly do have debug and release builds being made throughout the chain.

If you ship to externals I reckon you need to consider that the DLLs that go out need to be the same to all users, otherwise you risk not being able to easily debug issues later (configuration tracking from source code to delivered executables.)

Answer 5

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