正确使用子模块的

我有一个库我这样的结构中写道：正确使用子模块的

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

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

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

来源

2010-06-21 Sam Pearson

你真的在解决方案之间共享源代码吗？或者你真的需要编译“解决方案A”，然后与其他解决方案共享它的类库DLL？ – David 2010-06-21 22:08:31

这实际上是我一直在做的事情，但随着越来越多的解决方案涉及到SolutionA，当我进行更新时，将新的dll复制到每个解决方案成为一件麻烦事。 – 2010-06-21 22:21:29

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

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

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

有意义吗？

来源

2010-06-21 22:10:19 NotMe

我明白你的意思了，但是我需要我的构建服务器能够将它自己构建SolutionB所需的东西拉到什么位置。我可以在构建服务器上手动设置.sln结构，并将其存储到该文件夹中，但我宁愿在这里制定一个克隆n-go策略。（构建服务器 - > git克隆uri/to/SolutionB.git - >去）。 – 2010-06-21 22:24:56

（可能有一个子模块init + update，TeamCity的git插件可以配置为这样做） – 2010-06-21 22:26:20

第二个想法是，未来我可能会最终使用这个解决方案（经过几次修改）。这些存储库之间的共享资源太多，无法复制到每个存储库中，而且我正在编写如此多的定制应用程序，所以会有更多的存储库。 – 2010-06-22 00:29:17

你可以用git-submodules来解决这个问题（你的标签让我最高认为你使用git）。我不知道这种东西的“惯例”是什么。

至于回复我question关于如何处理子模块，dirk建议使用的NuGet（.NET Framework的包管理器。看到http://nuget.org），以解决相关的问题。似乎很适合你，因为如果你需要它，并且（至少在客户端）有良好的工具支持，你可以控制dll的依赖管理更新。

Scott Hanselmann有很好的article如何将nuget集成到持续集成中。

来源

2012-03-09 13:18:43 plaugg

正确使用子模块的

回答

相关问题