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

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

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

但是,同样地,我们也用适当的属性标记了许多基类,以使调试器完全跳过它们,因为在您自己的类(在您正在开发的级别)中所做的任何调试都只会被来自基库的代码大大超出。当你击中 步入 在一个库类上调试快捷键,您可以在当前级别上重新进入下一段代码,而不必费力地浏览大量的库代码。

基本上,我肯定会投票赞成(从这样的角度来说)你关于让普通开发人员看不到经过验证的库代码的评论。

另外,如果我加载包含所有项目的全局解决方案文件,基本上,就是所有的项目,resharper 4似乎有某种冠状动脉问题,因为Visual Studio实际上已经停止工作了。

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

如果不这样做,则意味着当引用的项目更改时,您的代码将神秘地中断。但只有在一些机器上。

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

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

至于你提到的项目参考的好处,我不同意你的第二点。对我来说,重要的是消费项目明确地知道他们消费的是公共库的哪个版本,并且对他们来说,采取一个深思熟虑的步骤来升级这个版本。这是确保您不会意外地获取尚未完成或测试的库更改的最佳方法。

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

我这样做是为了让开发人员能够打开一个只有域、测试和Web项目的紧密解决方案。我们的Win服务、Silverlight产品和Web控件库都是独立的解决方案,其中包括您在查看这些项目时需要的项目,但Nant可以构建所有这些项目。

我相信您的问题实际上是关于项目在同一个解决方案中何时结合在一起;原因是同一个解决方案中的项目应该彼此具有项目引用,而不同解决方案中的项目应该彼此具有二进制引用。

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

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

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

我简单地用概念来区分它