跨多个项目包含共享库的正确方法是什么（出于 CI 的目的）答案

【问题标题】：What's the correct way to include shared libraries across multiple projects (for purpose of CI)跨多个项目包含共享库的正确方法是什么（出于 CI 的目的）
【发布时间】：2011-07-21 11:13:24
【问题描述】：

我的项目结构如下所示：

[解决方案名称]
- doc（文档）
- extlib（多个源项目依赖的外部库）
  - [Nunit]
  - [FluentValidation]
  - 等
- src（源代码）
  - 解决方案文件
  - [C#库项目文件夹]
  - [MVC 3 项目文件夹]
  - [NUnit 测试项目文件夹]

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

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

我敢打赌，有更好的方法可以做到这一点（可能是 NuGet 包？）除了我尝试在此处设置构建过程的方式之外，最佳实践是什么？

更新：仅供参考，我知道导致错误的原因。这是因为 extlib 文件夹在我的源项目之上，但我只将源项目拉到他们的工件文件夹中进行构建。所以，为了修改这个问题，我想知道这是重新配置我的所有 CruiseControl 设置的更好途径，还是在每个项目中使用 NuGet 包等更好。

提前感谢您提供的任何帮助！

-- 肖恩

【问题讨论】：

ccnet 错误是什么？你能从你的csproj文件中粘贴一个sn-p吗？
ccnet的错误是没有找到FluentValidation库。再一次，这很有意义，因为我从我的 extlib 文件夹中引用了 fluentValidation，而 ccnet 没有它可用。我认为这可能与我提取源代码的方式有关。对于每个项目，我将分别提取其文件夹。我想我应该拉整个 repo 并检查文件夹是否有更改。

标签： c# msbuild continuous-integration dependencies cruisecontrol.net

【解决方案1】：

我在工作中也有同样的情况。我们曾经有一个单一的网络位置，我们将项目使用的所有第三个库和项目 dll 的输出（工具包、日志记录等...）放在其中。

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

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

优点：

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

缺点：

增加源代码控制存储库的大小
???

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

编辑：

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

【讨论】：

【解决方案2】：

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

【讨论】：

这是我最终采用的解决方案。谢谢！

【解决方案3】：

CCNET 不必知道外部库，因为对外部库的引用条目将位于每个单独的 .CSPROJ 文件中。你能确定以下事情吗

确保 extlib 文件夹存在于预期位置
确保所有项目引用外部 dll 有正确的条目 wrt extlib 在 .CSPROJ 文件中（您可以编辑和看看这个）。

【讨论】：

嗨 Kumar，请查看我刚刚进行的更新。这绝对是问题所在，我应该在我的问题中措辞更好。它只是提出了一个理论问题——我应该改变我的 CCNet 项目的拉取/构建方式，还是应该在每个需要它们的项目中使用 NuGet 包？更多的是关于如何从那里开始的问题。谢谢！
在这种情况下，我建议重新配置 ccnet 设置以正确指向它，因为您非常接近完成它，而不是花费时间重新设置 NuGet pckg（尽管这是一个好方法否则使用）。