As I was surprised about the ugliness of various file versioning implementations I’ve seen over the years in various build scripts I decided to write a small guide on how you should do it.
Do not, ever, do find-and-replace inside the source-code in order to replace version numbers. The version should be stored in a single place and the revision number should be generated automatically.
If after you run the build scripts you do have source files modified on disk, you can be sure that you are doing something deeply wrong. If you are using git just run
git status, which should return:
nothing to commit, working directory clean
First we need to establish a common language for naming each component of versioning. As Microsoft decided that versions are supposed to be formed only from 4 integers that can have values between 0-65500 you should not use the build number in the last integer. You will be surprised how often people are faced with serious problems because their build number passed 65535.
As we cannot use the sha1 form the source control we will have to be a little bit creative and generate a numeric revision number.
At this moment I am using this piece of code to generate an incremental numeric revision:
REVISION- generated from the SCM or build system, defaults to 0 for dev builds. In many cases this can be the build number.
VERSIONwould be ``$MAJOR.$MINOR.$PATCH
Convincing msbuild to put the correct version numbers on builded files can be obtained only by tunning a little bit the project files in order to generate the assemblies files, instead of modifying them at each build.
Once you implemented these changes the only thing you need to add is a parameter to msbuild calls, like:
msbuild.exe /nologo /maxcpucount /verbosity:minimal project.sln /p:Configuration=Release /p:VERSION=18.104.22.168
In order to use the same version as you used on
msbuild for your installer, just do
makensis.exe /V1 /DVERSION=%VERSION% installer.nsi and inside your .nsi` file you will want to have to do something like: