.net - C# .Net 的编译器缓存解决方案

Question

我们有一个大型 TFS 安装，有数百名开发人员正在处理 500MB 的源代码。目前，我们正在使用功能驱动的方法进行开发，并为每个功能创建一个新分支。您可以争论这种方法的合理性，但它会造成以下情况:

开发人员将拥有多个 95% 相同的分支。多个开发人员将拥有相同的分支，甚至相同的版本。仅定期构建生产和集成分支，因此为了做任何有用的事情，每个开发人员都必须构建他们需要的每个分支。构建时间大约需要 1-2 小时才能构建完所有内容。

我们通过连夜构建所需的分支并在实际开发过程中仅构建单个模块来解决这个问题。尽管如此，每个开发人员都会多次编译完全相同的程序集，只是在不同的分支中。但有时您需要在工作期间完全构建一个分支。

是否有适用于 TFS/Visual Studio 的“企业级”编译器缓存解决方案？我已经将 ccache 与 gcc 一起使用，但我几乎不知道如何将其集成到 .Net 环境中。谷歌搜索这个问题也没有找到太多信息。

Answer 1

当解决方案中有许多项目时，构建时间会急剧增加。 C# 编译器会重新分析每个被复制的 dll，因此从某种意义上说，“复制本地”选项是邪恶的。

有关可能的解决方案，请查看 these two articles通过 Patrick Smacchia :

• Partitioning code base through .NET assemblies and Visual Studio projects
• Defining .NET Components with Namespaces

简而言之，构建时间随着项目数量呈指数增长，因此，您应该尝试通过将所需项目合并在一起来最小化所需项目的数量。项目/程序集通常用于强制架构边界(我也像这样使用它们)，但这对于大型项目来说并没有什么用处。相反，您可以使用诸如 NDepend 之类的工具。验证架构规则，并防止类型之间的循环依赖。您可以通过对命名空间中的类型进行分组以及对每个功能的类型进行分组来实现此目的。

不过有一点要注意。我已经使用了 Partitioning code base through assemblies 上的建议在我的一个开源项目中，Simple Injector 。项目不直接引用其他项目，而仅引用程序集。这样做的缺点是 Visual Studio 转到引用选项 (F12) 不再起作用，因为 VS 不再了解有关该项目的任何信息。 VS 不会跳转到代码，而是跳转到仅包含类型的 API 定义的生成文件。在咨询了 Patrick Smacchia 后，他解释说他从未经历过这种情况，可能是因为他的团队使用 Resharper，它似乎仍然知道如何跳转到代码。

结论是，您需要对此进行试验，并且可能希望为所有开发人员提供一个生产力工具，例如 Resharper，它允许您仍然“跳转到代码”。您需要一个诸如 NDepend(NDepend 很棒)之类的工具，并将其集成到构建过程中，以确保开发人员不会违反架构规则。

减少编译时间的另一个选择是拆分团队，使核心库团队成为“外部”团队。这些团队可以开发、版本化和发布可重用库作为 DLL，其他团队可以将其包含在他们的解决方案中(并将该特定版本 checkin 源代码管理)。这使这些团队(可能是产品团队)不必编译基础库，并且由于这些 DLL(在解决方案中)放置在一个文件夹中，因此您可以立即获得性能提升，如 Pattrick 的文章中所述。这对开发盒和构建服务器上的编译时间都有积极的影响。

这种方法的缺点是您(再次)无法“跳入”该代码，并且开发核心库的过程将更加严格。这些库成为可重用的框架，并且您无法轻松更改这些库的公共(public) API。产品/功能开发人员也不能简单地添加/更改代码或修复核心库中的错误，他们需要等待核心团队发布新版本。但是，根据您组织当前的规模(数百名开发人员)，您可能已经需要(或拥有)这样的结构。