How to update master solution automatically when dependencies are added?

Question

We are using the single master solution strategy in more than one software project, and recently somebody added a dependency in common code which broke the other project's solution until the new dependency was added to their solution. What's a good strategy to eliminate or minimize this kind of issue?

We've thought of the following:

• Add a keyword to the checkin log message to tell other projects to add the dependency (but this is a manual process)
• Work with multiple partitioned solutions instead of a single master solution (resulting in longer build times, loss of intellisense across solutions, etc.)
• Use a tool to create a master solution from multiple partitioned solutions (any suggestions that work with VS2015, and can this be automated?)

Our largest single master solution so far is 115 project files, so on that basis alone it doesn't seem like partitioning the solution is necessary unless that's the best way to solve our problem.

If you have run across this problem, how did you solve it?

Answer 1

There is probably no built-in way to do it (none of the MSBuild files installed by any version of VS perform a build of the projects, and there's feature requests for it like this one). A pretty quick solution is to create an msbuild file which builds referenced project as a pre-build event and include that file in each project which references another project. For example, create a file named buildprojectreferenecs.targets in a directory with common build tools or so, with content

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="BuildProjectReferences" BeforeTargets="BuildGenerateSources">
    <MsBuild Projects="@(ProjectReference)"
             Properties="Configuration=$(Configuration);Platform=$(Platform)"/>
  </Target>
</Project>

This simply builds each ProjectReference with the same Configuration and platform as the project including it. Import this in each project which uses projectreferences. The import has to occur after the ProjectReference item is defined, so put it e.g. all the way at the bottom:

  ...
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" /> <!-- this is near the bottom already -->
  <Import Project="..\BuildProjectReferences.targets" /> !<-- add this -->
  ...
</Project>

Now if you run a build, before actual compilation starts a build of the referenced projects will occur (and of their referenced projects in turn, etc) no matter if they are in the solution or not. Some disadvantages:

• if you add a project refernce but forget to import this file nothing happens
• the build occurs unconditionally, so if the reference project is built already a build is started again; though it will also finish immediately since the build system sees all outputs are up-to-date
• the build system in VS won't detect changes to referenced projects outside of the solution, so if all projects in the solution are up-to-date and you change a source file in a referenced project outside of the solution it won't be built. This is not the case for commandline builds though, there a build of projects will start and hence the referenced projects will be built as well.

All in all, I'm not sure if it's worth it. Since you opted for the 'single master solution' approach arguably the solution should really be the single solution for the project and as such must contain all dependencies which are built from source. And it's the developers' task to make sure that happens. To catch failures to do so fast the best solution is having a build server which builds each commit to the codebase and as such discovers errors fast. Developers are then notified of their mistakes as well and will apply the fix soon (especially since it's trivial).