在多个项目中包含共享库的正确方法是什么（用于CI的目的）

Question

我的项目结构如下所示：

• [解决方案名称]
  • doc（文档）
  • extlib（外部库依赖于多个源项目）
    • [NUnit的]
    • [FluentValidation]
    • 等
  • src（源代码）
    • 解决方案文件
    • [C＃库项目文件夹]
    • [MVC 3项目文件夹]
    • [NUnit Test Project文件夹]

我在CruiseControl .NET中为每个项目都有一个构建过程。但是，例如，当我在我的库项目中包含FluentValidation时，它位于“extlib”的位置之外，CruiseControl不知道该目录并引发错误。

我想将所有外部库保存在一个地方（相同版本等），但这是否真的有必要？

我认为有更好的方法可以做到这一点（可能是NuGet包？）在我尝试设置构建过程的方式中，最佳实践替代方法是什么？

更新：仅供参考，我知道导致错误的原因。这是因为extlib文件夹位于我的源项目之上，但我只在其工件文件夹中提取源项目以进行构建。因此，为了修改这个问题，我想知道是否更好地重新配置我的所有CruiseControl设置，或者如果在每个项目中使用NuGet包更好，等等。

预先感谢您提供任何帮助！

- 肖恩

Answer 1

CruiseControl.NET在解决方案级别工作更自然。我建议检查整个存储库并为每个项目使用不同的触发器（正如您在自己的注释中所说的那样:)。）

Answer 2

我的工作情况相同。 我们曾经有一个网络位置，我们放置了项目使用的所有第三个库以及项目dll的输出（工具包，记录等...）。

我们所做的是ECI（企业持续集成）。你可以阅读它here。 我们在ccnet用户邮件列表上讨论过它，主题是here。

基本上，你的extlibs是你的源控制文件夹，CI工具在进行更改时会自动更新它们（例如通过单元测试）。

专业人士：

• 您可以在基本砖块中进行更改，而无需对每个依赖于它的项目测试效果，cc.net会为您验证。
• 你可以继续开发大项目，即使你的小砖的新版本（暂时）不兼容

缺点：

• 增加源控件存储库的大小
• ???

至于反馈，一些开发人员需要时间来理解这个过程，但他们都对新系统更加满意，他们可以提交更改，并在几分钟内看到他们是否打破了另一个项目。他们的部署现在更加平静！

编辑：

抱歉，我误解了您的问题，但我的反馈仍然有用。为什么不检查“解决方案名称”节点上的文件而不是src文件？

Answer 3

CCNET不必知道外部库，因为外部库的引用条目将出现在每个单独的.CSPROJ文件中。你能确定下面的事情

• 确保extlib文件夹存在于预期位置

• 确保所有项目 引用外部dll具有适当的条目和extlib 在.CSPROJ文件中（您可以编辑和 看看这个。）