Question

I see developers frequently developing against a solution containing all the projects (27) in a system. This raises problems of build duration (5 minutes), performance of Visual Studio (such as intellisense latency), plus it doesn’t force developer’s to think about project dependencies (until they get a circular reference issue).

Is it a good idea to break down a solution like this into smaller solutions that are compilable and testable independent of the “mother” solution? Are there any potential pitfalls with this approach?

Answer 1

Let me restate your questions:

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

The MSDN article you linked makes a quite clear statement:

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.

Moreover, the article recommends that you always have a single “master” solution file in your build process.

Are there any potential pitfalls with this approach?

You will have to deal with the following issues (which actually can be quite hard to do, same source as the above quote):

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.