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

Question

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

将这样的解决方案分解为独立于“母”解决方案的可编译和可测试的较小解决方案是否是个好主意？这种方法有什么潜在的缺陷吗？

Answer 1

让我重申你的问题:

Is it a good idea to break down a solution like this into smaller solutions

MSDN article you linked做了一个非常明确的声明:

Important Unless you have very good reasons to use a multi-solution model, you should avoid this and adopt either a single solution model, or in larger systems, a partitioned single solution model. These are simpler to work with and offer a number of significant advantages over the multi-solution model, which are discussed in the following sections.

而且，文章推荐你 总是 在您的构建过程中有一个“主”解决方案文件。

Are there any potential pitfalls with this approach?

您将不得不处理以下问题(这实际上很难做到，与上述引用的来源相同):

The multi-solution model suffers from the following disadvantages:

• You are forced to use file references when you need to reference an assembly generated by a project in a separate solution. These (unlike project references) do not automatically set up build dependencies. This means that you must address the issue of solution build order within the system build script. While this can be managed, it adds extra complexity to the build process.
• You are also forced to reference a specific configuration build of a DLL (for example, the Release or Debug version). Project references automatically manage this and reference the currently active configuration in Visual Studio .NET.
• When you work with single solutions, you can get the latest code (perhaps in other projects) developed by other team members to perform local integration testing. You can confirm that nothing breaks before you check your code back into VSS ready for the next system build. In a multi-solution system this is much harder to do, because you can test your solution against other solutions only by using the results of the previous system build.