14

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

支持项目引用的一些论据：

  • 项目引用将允许用户调试和查看所有解决方案代码，而无需加载其他项目/解决方案的开销。
  • 项目参考将有助于跟上提交给源代码控制系统的常见组件更改，因为如果没有活动的解决方案，更改将很容易识别。

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

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

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

4

6 回答 6

5

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

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

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

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

此外，如果我加载包含所有项目和基本上所有项目的全局解决方案文件，ReSharper 4 似乎存在某种冠状动脉问题，因为 Visual Studio 实际上陷入停滞状态。

于 2008-09-05T19:13:03.727 回答
2

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

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

于 2008-09-05T19:24:05.167 回答
2

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

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

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

于 2008-09-05T19:45:16.130 回答
1

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

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

于 2008-09-05T19:28:23.347 回答
1

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

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

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

于 2008-09-05T19:31:24.697 回答
0

我认为，如果该项目不是解决方案的一部分，则不应将其包含在其中……但这只是我的看法

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

于 2008-09-05T19:26:34.507 回答