What's up with xxx.sln.cache?

We have an infrastructure in developer division for performance measurement. Before a feature crew integrates into their product unit branch, or a product unit does one of their periodic integrations of changes into a main branch, they must pass RPS ("regression prevention system"). This runs of the order of 100 performance scenarios in a clean, isolated environment to get very precise numbers and a whole bunch of performance counters. If certain counters regress - elapsed time, disk I/O, or memory allocations I think - the run is rejected and the performance regression must be fixed before integration can occur. Towards Orcas RTM MSBuild was still missing a performance goal for certain command line solution build scenarios and we had to find a quick way to speed them up.

When you launch MSBuild.exe on a solution file -- either directly, or using Team Build - some code has to run to create an in-memory equivalent MSBuild format project file that MSBuild can actually build. Ideally this ought to be trivial. We would essentially construct a project file that simply ran the MSBuild task on all projects listed in the solution. In reality not all projects in the solution are in MSBuild format, most especially VC projects. It turns out that we have to load and evaluate every project in the solution to get some information we need to order the solution file correctly with respect to those VC projects, and in 3.5 we also have to figure out possible parallelism between projects in the solution. After this is done, we build the result, which of course involves loading and evaluating those projects again to actually build them.

You may have set MSBuildEmitSolution=1 in the past to see the resulting file. Editing this isn't supported, because the format will change from version to version, and it needs to be reconstructed if the solution is changed. However, it can be useful.

The solution cache file is a simple serialization of the in-memory solution file to disk. Much like MSBuildEmitSolution, but we read it too. When asked to build a solution file, MSBuild will use the solution cache if it's present and is valid for the configuration, tools version, and MSBuild version requested, and is up to date with respect to the solution file itself. This saves the time spent constructing the in memory solution project. It can go right ahead and build it.

This isn't very pretty, because it's exposing ugly implementation details in a plain text file. Also, there's no intermediate directory for a solution file like there is for a project, so we have to write it in the same directory, which is impolite, and not desirable if you wish to keep your source tree clean (for example, you have redirected your intermediate and output directories elsewhere). There is one other issue. You can't safely build the solution concurrently with two different configurations, because the configuration isn't part of the filename, and the content of the file is configuration specific. Team Build needs to do this.

The workaround for both issues is to set an environment variable to disable creating this file. Set MSBuildUseNoSolutionCache=1.

When solutions and VC projects are MSBuild format this kind of problem will go away.

Dan

[edit: fixed typo spotted by Cullen Waters]