Project Reference Vs File Reference?

主宰稳场 提交于 2019-11-27 18:32:09

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.

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.

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

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

Source

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

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

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

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

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

This is not true for file references.

Lofty Lion

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"

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

s

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!