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 ]

Comments

• Anonymous
  November 10, 2005
  You wrote: It is not clear to us, however, how many solutions this will negatively affect.
  
  Don't put a lot of thinking on this. I have a solution involvin 12 projects and need to rebuild its references (and dependecies) at almost every other week. When v.next comes out it won't bother me to do it again.
• Anonymous
  November 11, 2005
  Diego, thanks for the feedback! Just curious, why do you keep rebuilding your dependencies? Does your solution structure change so much week to week?
  
  --Sumedh
• Anonymous
  November 12, 2005
  Sumedh, I decided to write the answer in my own blog. Please, be warned that my English is not as good as yours!
• Anonymous
  May 15, 2009
  <a href= http://sonic-com-g.fruitnojaba.com >missions how to make</a> <a href= http://fukku-com.fruitnojaba.com >laguadia airport</a> <a href= http://www-sms-cha.fruitnojaba.com >maggie mickflys ct restaurant</a> <a href= http://www-mysiste.fruitnojaba.com >gospel of jude</a> <a href= http://basz-s-hu.fruitnojaba.com >the village church</a>