Parallelizing Visual Studio solutions

One of the MSBuild Team’s scenarios for multi-proc builds is the automatic parallelization of Visual Studio solutions. For this scenario, we want Visual Studio to automatically parallelize all “independent” projects, and serialize all “dependent” ones.

The key here is the separation of projects into the “independent” and “dependent” buckets. The separation is entirely based on project-to-project references and the ordering of projects in the “Project Dependencies” dialog. If the dependencies are not set up correctly, Visual Studio may end up building some dependent projects in parallel and thus break the build.

Visual C++ (VC) projects in Visual Studio 2005 have already adopted the “parallel by default” model. For any solution that contains VC projects, Visual Studio automatically builds the independent projects in parallel. For consistency with VC projects, we are thinking of adopting the same model for managed projects (C#, VB and J#), and reusing the same Visual Studio mechanisms for parallelism.

It is not clear to us, however, how many solutions this will negatively affect. If VS 2005 solutions that contain managed projects do not have their project dependencies set up correctly, when these solutions are opened in the next version of VS, their builds will break when they are automatically built in parallel. While this would not be ideal, the fix, of course, would be to update the project dependencies.

There are two ways to add project dependencies to the solution: project-to-project references (https://msdn2.microsoft.com/en-us/library/7314433t.aspx), or project build dependencies (https://msdn2.microsoft.com/en-us/library/et61xzb3). Setting up a project build dependency ensures the dependent project is built after the projects it depends on. Adding a project-to-project reference additionally passes the output assembly of the referenced project as a reference to the compiler while building the referencing project. (Note that VS 2005 allows adding a project-to-project reference to a project with an exe output.)

We are planning to use more formal means to gather data on real-world solutions, but in the meantime, we would appreciate your thoughts on this issue. You can add a comment to this blog entry, or send email to msbuild@microsoft.com.

[ Author: Sumedh Kanetkar ]