git-submodules - 在 .NET 解决方案中正确使用子模块

Question

我有一个我用这样的结构编写的库：

SolutionA\
--Source\
  --Core\
  --Tests\
--Tools\
  --TestFramework\
  --MockTool\
SolutionA.sln

我想将此作为SolutionB. 如果我将整个结构用作子模块，它会得到一堆SolutionB不关心的东西；它不在乎SolutionA.sln；它不在乎Tests\；它不在乎Tools\。真的，SolutionB只在乎Core\。

看起来我需要一个单独的存储库Core\。那么通常的做法是为 .NET 解决方案提供两个存储库，其源被其他解决方案使用？一个只用于（非测试）代码本身（加上所需的库），一个用于测试工具和解决方案文件？

score 1 · Accepted Answer

解决方案只是一个或多个项目的容器；它可能属于同一个“解决方案”文件夹或外部某处。

如果您有一个项目，在本例中为“Core”，那么您可以直接从一个或多个解决方案中引用该项目源。在这种情况下，解决方案A 和解决方案B。

像 Tests\、TestFramework\、MockTool\ 等无关的东西，除非 Core 需要，否则不必包含在您的其他解决方案中。

说得通？

score 0 · Accepted Answer

你可以用 git-submodules 解决这个问题（你的标签让我相信你使用 git）。我不知道这种东西的“通常做法”是什么。

在回答我关于如何处理子模块的问题时，dirk建议使用 nuget（.NET Framework 的包管理器。请参阅http://nuget.org）来解决相关问题。似乎很适合您，因为您将获得 dll 的受控更新、依赖管理（如果需要）以及（至少在客户端）良好的工具支持。

Scott Hanselmann 有一篇很好的文章如何将 nuget 集成到持续集成中。

2 回答 2