Gitversion: MajorMinorPatchTag - AssemblyVersion vs AssemblyFileVersion

Created on 28 Jul 2015 · 9Comments · Source: GitTools/GitVersion

I don't know if this is a bug or how it's suppose to be, so this is maybe more a question about the logic and thought behind MajorMinorPatchTag.

When using the MajorMinorPatchTag scheme the applied assembly versions look like this:

[assembly: AssemblyVersion("0.4.0.12")]
[assembly: AssemblyFileVersion("0.4.0.0")]
[assembly: AssemblyInformationalVersion("0.4.0-alpha.12+Branch...")]

The AssemblyVersion has number of commits(which is correct) but AssemblyFileVersion doesn't. When I look in the code I can see that AssemblyVersion is set according to the scheme(via AssemblySemVer). AssemblyFileVersion however is always set to MajorMinorPatch + ".0", which means that the MajorMinorPatchTag scheme actually is ignored?

Why isn't AssemblyFileVersion set to AssemblySemVer also? Does it course problems elsewhere?

The AssemblyVersion is hidden from file properties, so it can be confusing to see 0.4.0.0 when deep down it's actually 0.4.0.12. I know that AssemblyInformationalVersion for example shows 0.4.0-alpha.12+Branch... but that doesn't necessarily tell me the truth about the AssemblyVersion, unless MajorMinorPatch scheme is used.

If these version numbers really are suppose to be different then shouldn't it be the other way around, if you consider what the CLR cares about: AssemblyVersion?

[assembly: AssemblyVersion("0.4.0.0")]
[assembly: AssemblyFileVersion("0.4.0.12")]

In any case, I think both version properties should be set to the same version: 0.4.0.12 when using the MajorMinorPatchTag scheme. In fact couldn't they always be set to the same version?

Source

veccie

Most helpful comment

Hey Guys,

Just a thought on this one. Since the AssemblyVersion is used for referencing and AssemblyLoading, and AssemblyFileVersion is just a representation of the version / build of the assembly in question. Do you think it would be appropriate to have configuration items for all three of the Versions? for example:

assembly-versioning-scheme: MajorMinorPatch
assembly-file-version-format: '{MajorMinorPatch}.{CommitsSinceVersionSource}'
assembly-informational-format: '{FullSemVer}.{Sha}.{CommitDate}'

This would lead to an assembly that is pinned to the Major.Minor.Patch.0. However, the assembly file itself would have a version that could differ and include the build metadata or commits since version (Major.Minor.Patch.Commits). This would allow the two versions to float separately so that subsequent builds that haven't adjusted Major Minor or Patch could be dropped in to replace existing instances of that assembly with the same AssemblyVersion.

cjam on 13 Sep 2016

👍3

All 9 comments

Is this in the Task or the exe?

JakeGinnivan on 29 Jul 2015

Both:

Exe:
https://github.com/GitTools/GitVersion/blob/master/src/GitVersionExe/AssemblyInfoFileUpdate.cs#L38

Task:
https://github.com/GitTools/GitVersion/blob/master/src/GitVersionTask/AssemblyInfoBuilder/AssemblyInfoBuilder.cs#L42

veccie on 29 Jul 2015

@SimonCropp I think both should listen to the config?

JakeGinnivan on 29 Jul 2015

@veccie feel free to submit a PR for this, I agree. We should respect that setting.

JakeGinnivan on 23 Jan 2016

Hey Guys,

assembly-versioning-scheme: MajorMinorPatch
assembly-file-version-format: '{MajorMinorPatch}.{CommitsSinceVersionSource}'
assembly-informational-format: '{FullSemVer}.{Sha}.{CommitDate}'

cjam on 13 Sep 2016

👍3

I totaly agree with cjam, this would be the best solution.