Incremental builds work off the input / output concept in MSBuild targets. A target won't be run if it's outputs are fresh / newer than the inputs.
As it stands, CroMagVersion doesn't use inputs / outputs properly and totally breaks incremental builds. To address this, the current approach is to use a build variable CROMAG to say 'use CroMag for this build'. This allows local DEBUG builds to not use CroMag, and to only invoke CroMag on release build.
In a solution with many projects, we should be able to do better. A solution will share a single version.props, so therefore, once a single project has read the git / mercurial metadata, we should be able to save other projects from repeatedly executing the CroMagVersion target after SharedAssemblyInfo.cs has been created once.
I'm not sure this is even possible, but effectively... the input for CroMagVersion needs to be the build start time.. perhaps written into a variable conditionally when the build starts. If the variable has no value, set it... if it does, do nothing. Therefore there will be an initial race to write a newer SharedAssemblyInfo -- but at least in theory, it should only be written once if the current date is used as input.
Again, not sure this is possible.. but perhaps we can ask an MSBuild expert / run some experiments.