项目参考与文件参考？

Question

可以在项目中以两种方式添加引用。

1. 项目参考。
2. 文件参考。

但是，何时使用Project以及何时使用File reference？

Answer 1

您没有指定，但我猜您是指Visual Studio？

项目引用和文件引用之间的主要区别在于是否有可用的实时更新。在项目参考中，您将能够通过Intellisense等项目立即在另一个项目中看到编辑在一个项目中的效果。因此，如果您添加名为Foo的类，则此类型将立即显示在intellisense中的任何项目中，该项目具有该项目的项目引用。

另一方面，文件引用只能看到磁盘上存在的更改。必须执行编译并将位写入磁盘才能查看更改。

通常，最好使用项目参考。

需要考虑的另一个角度是项目的相对语言。如果两个项目中的语言相同，则项目到项目引用最有用。如果语言不同，则往往更像文件引用而不是项目引用。

Answer 2

我刚刚经历过这个......

我们从供应商处收到了大约53种不同的VS2005 C＃解决方案文件，这些文件创建了63个不同的项目.dll，所有这些都由一个单独的商业应用程序调用。

所有项目都包含对其他项目的dll的文件引用。

这种方法的问题很棒：解决方案之间的依赖关系几乎不可能解决，涉及“findstr”命令的 lot ; VS的“查找定义”功能找不到文件引用的dll的源代码，它只显示dll内部函数的定义;由于更改而重建是容易出错，繁琐，并涉及打开许多不同的解决方案来重新构建整个dll集。

我花了数周时间将53个不同的解决方案文件合并为一个，然后花了额外的时间将所有文件依赖项更改为项目依赖项。现在，当您“找到定义”时，您将被带到源文件。现在，当您更改一个低级项目时，所有依赖项目将在您构建（一个）解决方案时构建。

我做了一些额外的更改，但最方便的是将所有单独项目的构建目录设置为 solutiondir / bin。这样，所有的dll都会在一个地方结束。

哦，是的：我还为所有引用项目的dll设置'copy local'为'no'。这样，每个dll都会在项目构建时显示在 solutiondir / bin中，并且可以在下一个要构建的项目中找到。

我们现在唯一的问题是，如果我使用Windows窗体更改用作另一个项目的数据源的项目，那么在重新构建作为数据源的项目之前，Windows窗体将不会在Designer中打开表格。一个小的，小的价格，以支付项目参考的所有好处。此外，我必须在结账时从svn构建解决方案，因为dll不在svn中。在上面的例子中，数据源.dll不在那里供Designer查找。

Answer 3

使用“项目引用”在解决方案中添加对程序集的引用。

使用“文件参考”添加对交叉解决方案程序集的引用

Source

Answer 4

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 5

我遇到了多个项目的问题，文件引用只是没有删除它。过时的引用导致buku问题。 Microsoft建议我们仅在必要时使用文件引用：

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

Answer 6

在大多数情况下，我专门设置我们的开发团队使用文件引用而不是项目引用： 我们在高度完整的领域运营。因此，不应该直接直接部分工作的每个组件（即在其他项目中共享的东西）不应该随时改变。 因此，我们的想法是（在一个理想的非绿地工作中）我们从网络上的发布区域获取经过测试，授权的已知版本的子组件，并将它们包含在解决方案的组件区域中。

这是为了简化维护和测试，因为它应该避免许多类似的版本激增，所有版本都有不同的版本或SVN编号。

第二个原因（可能是我的C / C ++背景）是我想知道我正在使用所有Debug或所有Release版本。你不能在.NET项目中轻松完成这项工作。我们构建一个components \ $ configuration $目录，然后进行一个构建后步骤，从components \ $ configuration $复制到上面的目录。 所有文件引用都只是组件目录中的文件，这意味着（我相信）我们确实在整个链中都进行了调试和发布构建。

如果您发送到外部，我认为您需要考虑出去的DLL需要与所有用户相同，否则您可能无法在以后轻松调试问题（从源代码到交付的可执行文件的配置跟踪）。 ）

Answer 7

最后，所有引用都是文件引用，Project Reference只是一个visual studio功能，它引用了使用您的解决方案构建的文件，因此无论何时构建新构建，引用都是无需复制即可自动更新粘贴文件

Answer 8

我选择文件参考的原因（即使我拥有源代码或自己创建了程序集）是指特定程序集不会发生很大变化（比如每半年一次）。只是为了节省一些构建时间。此外，一些项目会自动增加其版本号（例如，尝试在解决方案中包含AjaxControlToolkit项目）。

Answer 9

重建项目时，项目引用它的所有项目也会自动重建。

对于文件引用，情况并非如此。

Answer 10

切换到引用时（和删除相对包含）我遇到的一个错误（C1083）是“未找到标头”。我有：

首选项中的
• 包括目录：../../src/module
• 源代码：#include "file.h"

---

修正它的相对路径：

#include "module/file.h"

Answer 11

实际上两种方法都使用File引用。项目引用对于VS知道何时应该构建引用的VS项目

非常有用

取值