.NET配置GIT环境和本地构建,以处理具有它们之间依赖关系的多个存储库

时间:2014-04-19 21:32:21

标签: .net git visual-studio-2012 build

我们有多个团队在分成多个存储库的大型项目上一起工作,每个团队在一个或多个存储库上工作,一些存储库在团队之间共享。 作为一项安全策略,我们不允许开发人员访问所有存储库,只能访问其项目所需的存储库。 目前我们的dev文件夹如下所示:

Repos.Folder
  Repo1
  Repo2
  ...
  RepoN
  bin.folder

开发人员首先从构建服务器下载所有dll到bin文件夹,所有项目输出到bin.folder以及通过visual studio本地构建。

问题是,因为并非所有开发人员都拥有所有项目,我们无法将项目引用到.csproj文件(因为不是每个人都会有这些引用),但我们将它们引用到bin文件夹中的dll文件 - 所以所有开发人员都可以从构建服务器下载它们,因此,当开发人员尝试设置工作空间解决方案(.sln文件)时,visual studio不会自动检测项目的构建顺序,因此每个开发人员都需要自己设置sln文件通过每个项目参考 - 这是一个巨大的开销......

想要问某人是否有针对该问题的解决方案,或者有人在我们的开发环境中发现警告/问题并知道如何更好地处理它。

谢谢,

詹姆斯

1 个答案:

答案 0 :(得分:0)

首先,我会质疑防止某些开发人员访问某些代码的安全性是否真的超过了它所引起的问题。

但是,假设给定的情况,我会考虑使用NuGet

每个项目都可以发布它自己的NuGet包,最好是using a build server,它为每个构建和包生成一个唯一的语义版本(理想情况下还与版本控制系统的版本号相结合)。

您可以将NuGet包发布到内部Feed(例如a file share or an internally hosted NuGet server)。

NuGet包可以具有反映项目之间依赖关系的依赖项。您可能不希望将项目置于同一解决方案中。

这样,项目之间的依赖关系完全独立于实际的源代码。您也没有版本控制任何二进制文件。相反,通过从packages.config文件中读取版本号,可以清楚地看到特定代码所依赖的确切版本。这也使得版本控制和代码合并更容易。它还使项目更少耦合,并使得最终组件更具可重用性。

然而,需要注意的一个缺点是修改依赖关系然后在另一个项目中使用它将变得更加麻烦。最直接的方法是使用构建服务器更新NuGet包,然后更新使用项目中的NuGet包。