iristyle / cromagversion Goto Github PK

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.

If multiple solutions are in a single repository, then there will be a race condition of sorts that happens, since the SharedAssemblyInfo.cs is shared amongst all solutions / projects sharing the given package.

So if solution A is using version 1.0.0.0 and solution B is using version 2.0.0.0... and they each have multiple projects, but live in the same solution, there may be issues where A projects end up with 2.0.0.0 and B projects end up with 1.0.0.0.

Each project in each solution recreates the SharedAssemblyInfo.cs file before building / incorporating it.... but there's a window of time between when the file is written and it's used in the build -- so there is an opportunity for another csproj file to blow away the file before it's compiled with version information that may not be correct for that project. Perhaps this generated file can be placed moved to the build configuration obj directory instead of using something underneath of the nuget packages folder?

Chew on this for a bit... still need to be able to reference the file from inside the csproj, and need to output the file to a place that is not excluded from DVCS.

Admittedly this is an edge case, and perhaps should be punted on... but documented anyhow. No real world issues with this at the moment.