具有大量项目的Visual Studio解决方案

Question

我看到开发人员经常针对包含系统中所有项目(27)的解决方案进行开发.这引发了构建持续时间(5分钟),Visual Studio性能(例如智能感知延迟)的问题,而且它不会强迫开发人员考虑项目依赖性(直到他们得到循环引用问题).

将这样的解决方案分解为可编译和可测试的独立于"母"解决方案的小型解决方案是一个好主意吗？这种方法有任何潜在的缺陷吗？

Answer 1

让我重申一下你的问题:

将这样的解决方案分解为更小的解决方案是一个好主意

您链接的MSDN文章做了一个非常明确的声明:

重要 除非您有充分的理由使用多解决方案模型,否则应避免这种情况并采用单一解决方案模型,或采用较大系统中的分区单一解决方案模型.与多解决方案模型相比,它们更易于使用并提供许多显着优势,这将在以下各节中讨论.

此外,本文建议您在构建过程中始终拥有一个"主"解决方案文件.

这种方法有任何潜在的缺陷吗？

您将不得不处理以下问题(实际上可能很难做到,与上面的引用相同):

多解决方案模型存在以下缺点:

• 当您需要在单独的解决方案中引用项目生成的程序集时,您将被迫使用文件引用.这些(与项目引用不同)不会自动设置构建依赖项.这意味着您必须解决系统构建脚本中的解决方案构建顺序问题.虽然可以对其进行管理,但它会为构建过程增加额外的复杂性.
• 您还被迫引用DLL的特定配置版本(例如,Release或Debug版本).项目引用自动管理它并引用Visual Studio .NET中当前活动的配置.
• 使用单个解决方案时,您可以获取其他团队成员开发的最新代码(可能在其他项目中),以执行本地集成测试.在将代码检入VSS并准备好进行下一次系统构建之前,您可以确认没有任何中断.在多解决方案系统中,这很难做到,因为您只能通过使用先前系统构建的结果来针对其他解决方案测试您的解决方案.