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

Question

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

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

我想将此作为SolutionB的子模块包含在内。如果我将整个结构用作子模块，它会得到一堆SolutionB不关心的东西;它不关心SolutionA.sln;它不关心Tests\;它并不关心Tools\。实际上，SolutionB只关心Core\。

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

Answer 1

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

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

除非Core要求，否则Tests \，TestFramework \，MockTool \等无关的内容不必包含在您的其他解决方案中。

有意义吗？

Answer 2

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

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

Scott Hanselmann有一个很好的article如何将nuget整合到Continous Integration中。