什么时候应该使用项目引用而不是二进制引用？

题

我的公司有一个通用代码库，其中包含许多类库项目以及支持测试项目。每个类库项目输出一个二进制文件，例如Company.Common.Serialization.dll。由于我们拥有已编译、测试的二进制文件以及源代码，因此对于我们的消费应用程序是否应该使用二进制或项目引用存在争议。

支持项目参考的一些论点：

支持二进制引用的一些论点：

二进制引用将简化解决方案并加快解决方案加载时间。
二进制引用将使开发人员能够专注于新代码，而不是被已经烘焙并证明稳定的代码分散注意力。
二进制引用将迫使我们适当地测试我们的东西，因为我们将使用公共库，就像我们组织外部的人需要做的那样。
由于无法调试（单步执行）二进制引用，因此将被迫通过扩展现有测试项目来复制和修复问题，而不是单独在使用应用程序的上下文中进行测试和修复。
二进制引用将确保类库项目的并发开发不会对使用应用程序产生影响，因为将引用二进制文件的稳定版本而不是流入版本。如有必要，项目负责人将决定是否合并该组件的更新版本。

在使用项目或二进制引用时，您的政策/偏好是什么？

解决方案

在我看来，您好像已经涵盖了所有要点。我们最近在工作中进行了类似的讨论，但尚未完全决定。

然而，我们研究的一件事是引用二进制文件，以获得您注意到的所有优点，但让二进制文件由通用构建系统构建，其中源代码位于公共位置，可从所有开发人员计算机访问（至少如果他们在工作时坐在网络上），这样如果有必要的话，任何调试实际上都可以深入到库代码中。

然而，同样的，我们还用适当的属性标记了许多基类，以使调试器完全跳过它们，因为您在自己的类中（在您正在开发的级别）进行的任何调试都会仅比基础库中的代码大得多。这样当你点击步入调试库类上的快捷键，您可以重新进入当前级别的下一段代码，而不必费力地浏览大量库代码。

基本上，我绝对投票支持（用SO术语来说）您关于将经过验证的库代码保留在普通开发人员的视线之外的评论。

另外，如果我加载包含所有项目和基本上所有内容的全局解决方案文件，ReSharper 4 似乎会出现某种严重问题，因为 Visual Studio 实际上会陷入停滞状态。

其他提示

在我看来，使用项目参考的最大问题是它没有为消费者的开发提供共同的基线。我假设图书馆正在发生变化。如果是这种情况，构建它们并确保它们的版本控制将为您提供一个易于重现的环境。

不这样做将意味着当引用的项目发生更改时，您的代码将神秘地中断。但仅限于某些机器。

我倾向于将像这样的公共库视为第三方资源。这允许库拥有自己的构建流程、QA 测试等。当 QA（或任何人）“祝福”库的发布时，它会被复制到所有开发人员都可以使用的中央位置。然后，由每个项目决定通过将二进制文件复制到项目文件夹并在项目中使用二进制引用来使用哪个版本的库。

重要的一件事是在库的每个版本中创建调试符号 (pdb) 文件并使其可用。另一种选择是在网络上实际创建一个本地符号存储，并让每个开发人员将该符号存储添加到他们的 VS 配置中。这将允许您调试代码，并且仍然具有使用二进制引用的好处。

至于你提到的项目参考的好处，我不同意你的第二点。对我来说，重要的是使用项目明确知道他们正在使用哪个版本的公共库，并让他们采取有意识的步骤来升级该版本。这是保证您不会意外拾取尚未完成或测试的库更改的最佳方法。

当您不想在解决方案中使用它，或者有可能拆分您的解决方案时，请将所有库输出发送到公共 bin 目录并在那里引用。

我这样做是为了让开发人员能够打开一个只有域、测试和 Web 项目的紧凑解决方案。我们的 win 服务、silverlight 以及 Web 控制库位于单独的解决方案中，其中包括您在查看这些项目时所需的项目，但 nant 可以构建这一切。

我相信你的问题实际上是关于项目何时在同一个解决方案中组合在一起；原因是同一解决方案中的项目应该相互具有项目引用，不同解决方案中的项目应该相互具有二进制引用。

我倾向于认为解决方案应该包含紧密一起开发的项目。例如您的 API 程序集和这些 API 的实现。

然而，亲密程度是相对的。根据定义，应用程序的设计器与应用程序密切相关，但是您不希望设计器和应用程序位于同一解决方案中（也就是说，如果它们非常复杂）。您可能希望针对程序的一个分支来开发设计器，该分支的合并间隔比正常的日常集成间隔更远。

我认为如果该项目不是解决方案的一部分，那么您不应该将其包含在那里......但那只是我的个人意见

简而言之，我按概念将其分开

许可以下： CC-BY-SA 和归因