One Solution or Many Solution Files?

In VS 2002/2003, C# and VB don't have any notion on being up-to-date or doing incremental builds. Because the time-stamp of C#/VB output assemblies always changes when you build, any projects that depend on them will always be out-of-date with respect to those assemblies and will need to be rebuilt. This story is somewhat better in VS 2005, but there still is no notion of an "incremental build" against an assembly dependency. So if the assembly has changed at all, no matter how minor the change, all of the dependent projects will have to be rebuilt. This can be a big performance hit on your build times.

How does Microsoft get around this? One answer is faster, bigger hardware, but a more practical one is the concept of the Central Build Team doing these large, time-consuming builds to make sure everything works and plays well. The developers would then use file references in their own private solution file to decrease build times. If the code changes in the referenced files, the IDE will not automatically rebuild it, so they might not get all the current changes. This can be problematic at best.

Here are some different ideas to get around this problem:

• Use a single solution file that contains all your .NET projects for a daily build, and keep that solution file checked into source control that the CBT owns. The Central Build Team members are the only ones allowed to make changes to the "golden" solution, and the developers put in a request to the CBT if they need to add or remove projects.

• Each developer has a "private" solution file on his machine (which I'm willing to bet he has already) that he does not check in to source control. This allows him to have faster build times and use file references instead of project references, thus avoiding long rebuild times.

• Another option is to break up the big single solution file and have each component team check in a "master" solution file that the CBT owns. This would take more time to set up but is probably the best way to build .NET projects.