2008-09-05 15 views
14

我的公司有一个共同的代码库,它由许多类库文件项目和支持测试项目组成。每个类库项目输出单个二进制文件,例如, Company.Common.Serialization.dll。由于我们拥有经过编译和测试的二进制文件以及源代码,因此我们的消费应用程序是否应该使用二进制或项目引用存在争议。什么时候应该使用与二进制引用相反的项目引用?

有利于项目引用的一些参数:

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

赞成二进制引用的一些参数:

  • 二进制的引用将简化的解决方案,并为更快的解决方案加载时间。
  • 二进制引用将允许开发人员专注于新代码,而不是被已被烘焙且已被证明是稳定的代码分散注意力。
  • 二进制引用会迫使我们适当地将我们的东西用于食物,因为我们将使用公共库,正如我们组织之外需要这样做的那样。
  • 由于无法调试二进制引用(步入),因此必须通过扩展现有测试项目来强制复制和修复问题,而不是单独在消费应用程序的上下文中进行测试和修复。
  • 二进制引用将确保类库项目的并发开发将不会影响消费应用程序,因为二进制文件的稳定版本将被引用而不是流入版本。如果需要的话,是否要引入新组件的更新版本将是项目主管的决定。

当涉及到使用项目或二进制引用时,您的策略/首选项是什么?

+0

这个问题缺少一个关键点imho,使用项目引用您可以使用交叉引用功能并使用工具来查找变量/方法的用法。二进制引用不提供此功能。 – 2015-08-26 07:45:09

回答

5

这听起来好像你已经涵盖了所有的要点。我们最近在工作中进行过类似的讨论,但我们还没有完全确定。

但是,我们研究过的一件事是引用二进制文件,以获得所有您注意到的优点,但是具有通用构建系统构建的二进制文件,其中源代码位于公共位置,可从所有开发人员的机器(至少如果他们在工作时坐在网络上),那么如有必要,任何调试实际上都可以潜入库代码中。但是,在同一个注释中,我们还用适当的属性标记了许多基类,以便让调试器完全跳过它们,因为您在自己的类中进行的任何调试(在“重新开发)只会大大超出基础库的代码。通过这种方法,当你在库类上调试快捷键Step Into时,你将重新进入当前级别的下一段代码,而不必遍历大量的库代码。

基本上,我绝对投票(以SO条款)你的意见,关于保持正常的开发人员不见了经验证的库代码。另外,如果我加载全局解决方案文件,其中包含所有项目,并且基本上只包含所有内容,ReSharper 4似乎有某种冠状动脉问题,因为Visual Studio几乎停滞不前。

2

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

不这样做意味着当引用的项目更改时,您的代码将会神秘地破坏。但只限于某些机器。

0

我认为,如果该项目不是解决方案的一部分,你应该不包括它那里...但是这只是我的意见

我的概念在短期

1

分开它,当你不不需要它在您的解决方案中,或有可能分解您的解决方案,将所有库输出发送到公共的bin目录并在那里参考。

我这样做是为了让开发人员打开一个只有Domain,测试和Web项目的紧密解决方案。我们的win服务,Silverlight和Web控制库都在单独的解决方案中,包括您在查看这些项目时需要的项目,但是nant可以构建所有项目。

1

我相信你的问题其实是关于项目在同一个解决方案中一起出现的时间;原因在于相同解决方案中的项目应该具有彼此的项目引用,并且不同解决方案中的项目应该具有彼此的二进制引用。

我倾向于认为解决方案应包含紧密合作开发的项目。比如你的API程序集和你的API的实现。

但是亲密是相对的。按照定义,应用程序的设计人员与应用程序密切相关,但您不希望将设计人员和应用程序放在同一解决方案中(如果它们完全复杂的话)。您可能希望针对与正常日常整合相距更远的时间间隔合并的程序分支开发设计人员。

2

我倾向于将这样的通用库当作第三方资源处理。这允许库拥有自己的构建过程,QA测试等。当QA(或任何人)“祝福”库的发布时,它被复制到所有开发人员可用的中央位置。然后由每个项目决定要使用哪个版本的库,方法是将二进制文件复制到项目文件夹并在项目中使用二进制引用。

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

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

相关问题