I have been looking at the build process for Visual Studio 2005 projects recently and this obviously includes playing with MSBuild. Firstly it's great to finally have a robust, extensible build tool that doesn't have to rely on Visual Studio but I'll let others wax lyrical on the benefits of MSBuild. Instead I'd like to take a minute to jot down some thoughts on the task I have just built.
I wanted to create a taks that would manage the version stamps on the assemblies in my solution. The currently accepted wisdom for managing versions says that assembly version ('AV' from now on) should be used as the externally facing indication of the version of your product and that file version ('FV' from now on) should be used both for internal identification of exactly what build of an assembly you are working with and also to distinguish external releases that are compatible (service packs for example).
So I suggest the following logic should be applied in when building a new version of your assemblies during the normal development cycle:
- If the AV Major/Minor is greater than the FV Major/Minor, change the FV Major/Minor to match the AV and set FV Build/Revision to 0. Actually in theory this should never happen unless someone has messed up the FV.
- If the AV and FV Major/Minors match and this is the first build of the day, increment the Build and set the Revision to 0.
- If the AV and FV Major/Minors match and this is not the first build of the day, increment the Revision.
When you get to Release Candidate ('RC') status for an external build then things change a bit. It is now time to freeze the Build and update the AV accordingly. From this point until the release ships, the revision on both the AV and FV should be incremented together. After the build ships the source tree is branched, the AV and FV Major/Minor should be reset to the next version of the product, the Build/Revision should be reset to 0 and the normal development cycle resumes.
In the meantime, some maintenance may be required on a released version of the product. The changes should be made in the correct branch of the source tree whilst the AV is kept constant. The FV Build/Revision will continue to increment as per the normal development cycle, but the RC version freeze is ignored this time so that the AV remains the same for the service pack as for the original release. The patched assemblies can be identified by their FV. Now this assumes that you don't actually make a breaking change to the service pack, if you do that then it would probably be better to increment the AV Build, but I haven't specifically handled that particular scenario in my task.
I will post my MSBuild completed task once I have ironed out the wrinkles...