visual-studio 项目参考与文件参考？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/973814/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Project Reference Vs File Reference?
提问by Dhana
References can be added in two ways in a project.
可以通过两种方式在项目中添加引用。
- Project Reference.
- File Reference.
- 项目参考。
- 文件参考。
But, When to use Project and when to use File reference?
但是，何时使用 Project 以及何时使用 File 引用？
回答by JaredPar
You didn't specify but I'm guessing you're referring to Visual Studio?
您没有指定，但我猜您指的是 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.
项目引用和文件引用之间的主要区别在于实时更新是否可用。在项目参考中，您将能够通过 Intellisense 等项目立即在另一个项目中看到一个项目中的编辑效果。因此，例如，如果您添加名为 Foo 的类，则此类型将立即显示在任何具有该项目项目引用的项目中的智能感知中。
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.
另一个需要考虑的角度是项目的相关语言。如果两个项目中的语言相同，则项目到项目的引用将非常有用。如果语言不同，它们往往更像是文件引用而不是项目引用。
回答by james
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.
我们从供应商那里收到了大约 53 个不同的 VS2005 C# 解决方案文件，这些文件创建了 63 个不同的项目 .dll，所有这些文件都由一个单独的商业应用程序调用。
All projects contained file references to the dlls of the other projects.
所有项目都包含对其他项目的 dll 的文件引用。
The problems with this approach were great: inter-solution dependencies were almost impossible to work out, involving a lotof "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.
这种方法的问题很大：解决方案间的依赖关系几乎不可能解决，涉及很多“findstr”命令；VS 的“查找定义”功能不会找到引用文件的 dll 的源，它只会显示 dll 中函数的定义；由于更改而重新构建容易出错、麻烦，并且涉及打开许多不同的解决方案来重新构建整个 dll 集。
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.
我花了数周时间将 53 个不同的解决方案文件合二为一，然后又花了额外的时间将所有文件依赖项更改为项目依赖项。现在，当您“找到定义”时，您将被带到一个源文件。现在，当您更改低级项目时，所有相关项目都将在您构建（一个）解决方案时构建。
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.
我做了一些额外的更改，但最方便的是将所有单独项目的构建目录设置为solutiondir/bin。这样，所有的 dll 都会在一个地方结束。
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.
哦，是的：我还将所有引用项目的 dll 的“复制本地”设置为“否”。这样，每个 dll 都会在项目构建时出现在solutiondir/bin 中，并被下一个要构建的项目找到。
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.
我们现在唯一的问题是，如果我使用 Windows 窗体更改用作另一个项目的数据源的项目，那么在我重新构建作为窗体数据源的项目之前，Windows 窗体将不会在设计器中打开。为获得项目参考的所有好处而付出的很小的代价。另外，我必须在从 svn 结帐时构建解决方案，因为 dll 不在 svn 中。在上述情况下，Designer 找不到数据源 .dll。
回答by Shoban
回答by Kiquenet
utils references:
实用程序参考：
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterLargedotNETProjects.aspx
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterLargedotNETProjects.aspx
http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx
http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx
回答by CZahrobsky
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:
我在多个项目中遇到了文件引用无法解决的问题。陈旧的引用会导致 buku 问题。Microsoft 建议我们仅在必要时使用文件引用：
回答by Steve
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 directlypart 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.
这是为了简化维护和测试，因为它应该避免许多类似的版本激增，所有版本都具有不同的构建或 SVN 编号。
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.
第二个原因（可能是我的 C/C++ 背景）是我想知道我正在使用所有 Debug 或所有 Release 版本。您不能在 .NET 项目中轻松做到这一点。我们构建到 components\$configuration$ 目录，然后有一个构建后步骤从 components\$configuration$ 复制到上面的目录。所有文件引用都指向组件目录中的文件，这仅意味着（我相信）我们确实在整个链中进行了调试和发布构建。
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.)
如果您发送给外部人员，我认为您需要考虑到所有用户都需要使用相同的 DLL，否则您可能无法在以后轻松调试问题（从源代码到交付的可执行文件的配置跟踪）。
回答by Martin Konicek
When a project is rebuilt, all projects that project-reference it are automatically rebuild too.
当一个项目被重建时，所有引用它的项目也会自动重建。
This is not true for file references.
这不适用于文件引用。
回答by bashmohandes
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
最后，所有引用都是文件引用，项目引用只是一个 Visual Studio 功能，它引用了正在使用您的解决方案构建的文件，因此无论何时构建新构建，该引用都会自动更新，无需你要复制和粘贴文件
回答by Colin
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).
我去参考文件的一个原因（即使我有源代码或自己创建了程序集）是当该特定程序集没有太大变化时（比如每半年一次）。只是为了节省一些构建时间。此外，某些项目会自动增加其版本号（例如，尝试在您的解决方案中包含 AjaxControlToolkit 项目）。
回答by Lofty Lion
One error (C1083) I had when switching to references (& removing relative includes) was "Header not found." I had:
切换到引用（并删除相关包含）时遇到的一个错误 (C1083) 是“未找到标头”。我有：
- in preferences include directory:
../../src/module - in source code:
#include "file.h"
- 在首选项中包括目录：
../../src/module - 在源代码中：
#include "file.h"
Fix the relative path for it to work:
修复相对路径使其工作：
#include "module/file.h"
#include "module/file.h"
