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

一些支持项目引用的参数：

• 项目引用将允许用户调试和查看所有解决方案代码，而无需加载其他项目/解决方案。
• 项目参考将有助于跟上对源代码控制系统所做的公共组件更改，因为在没有有效解决方案的情况下，更改是很容易识别的。

一些支持二进制引用的参数：

• 二进制引用将简化解决方案并缩短解决方案的加载时间。
• 二进制引用将使开发人员可以专注于新代码，而不必被已经烘焙且证明稳定的代码所分散。
• 二进制引用将迫使我们像使用公共库一样，对我们的内容进行适当的折衷，就像需要组织外部的库一样。
• 由于二进制引用无法调试(进入)，因此将不得不通过扩展现有的测试项目而不是仅在使用应用程序的上下文中进行测试和修复来复制和修复问题。
• 二进制引用将确保类库项目上的并发开发不会对使用的应用程序产生任何影响，因为将引用二进制的稳定版本而不是Influx版本。如有必要，是否要引入组件的较新版本将由项目负责人决定。

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

解决方案

回答

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

但是，我们研究的一件事是引用二进制文件，以获得我们注意到的所有优点，但是二进制文件是由通用构建系统构建的，其中源代码位于公共位置，所有开发人员机器均可访问(至少在他们坐在工作网络上的情况下)，这样，如果需要，实际上任何调试都可以深入到库代码中。

但是，同样，我们还为许多基类标记了适当的属性，以使调试器完全跳过它们，因为我们在自己的类中进行的任何调试(在我们正在开发的级别上)都将只能通过基础库中的代码进行大幅扩展。这样，当我们在库类上按下"进入调试"捷径键时，我们便可以重新进入当前级别的下一段代码，而不必费力阅读大量库代码。

基本上，我绝对赞成(用SO术语表示)意见，以使普通开发人员看不到经过验证的库代码。

另外，如果我加载包含所有项目以及基本上所有内容的全局解决方案文件，那么ReSharper 4似乎会遇到一些冠状动脉问题，因为Visual Studio实际上处于停滞状态。

回答

在我看来，使用项目引用的最大问题是它不能为消费者提供他们开发的通用基准。我假设图书馆正在改变。如果是这样，构建它们并确保对其进行版本控制将为我们提供易于复制的环境。

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

回答

我认为，如果该项目不是解决方案的一部分，则不应在其中添加它……但这只是我的意见。

简而言之按概念分开

回答

如果我们不希望在解决方案中使用它，或者有可能拆分解决方案，请将所有库输出发送到公共的bin目录中，并在其中进行引用。

我这样做是为了允许开发人员打开一个只有域，测试和Web项目的紧凑型解决方案。我们的Win服务，Silverlight东西和Web控件库位于单独的解决方案中，其中包括我们在查看项目时所需的项目，但是nant可以构建所有项目。

回答

我相信问题实际上是什么时候项目可以在同一解决方案中一起进行；原因是同一解决方案中的项目应具有彼此的项目引用，而不同解决方案中的项目应具有彼此的二进制引用。

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

但是，亲密关系是相对的。从定义上说，应用程序的设计者与该应用程序密切相关，但是我们不希望将设计器和该应用程序包含在同一个解决方案中(如果它们非常复杂，那就是)。我们可能想针对程序的一个分支开发设计器，该分支的合并间隔要比正常的日常集成间隔得更远。

回答

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

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

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