GitVersion: [Bug] Assembly Informational Version custumization ignored

Let me explain why I really need this feature. GitVersion is good for producing SemVer numbers for assemblies, but also for adding any git version related information to them, and GitVersionTask is also a way for us to automatically embed that info into dll/exe. Having a free text field that embeds GitVersion information is a key point for extensibility. Projects can take advantage of it for example by running a script that updates the GitVersion.yml assembly-file-versioning-format property appending whatever extra information that GitVersion can’t get, but it becomes messed up and hard to work with if the text gets replaced by dashes.

Not implementing this because of having too many configuration keys sounds a bit arbitrary. If the feature makes sense and adds a desired feature then why not? We can always change them, group them or whatever in the upcoming versions.

There could be many valid use cases to have free text, I will state one. In our company we use GitVersion to check the version of dlls in the servers so we know what was deployed (looking at the sha commit id). One of the problems we have at our company for example is that we need to know if the dll was built with local changes (isDirty) or not, since we have seen many cases of dlls deployed from developer’s local machines. Even if deploying a dirty compiled dll sounds bad, in practice it does happen and it is out of my reach to prevent, for example in small companies or when there is a deadline to meet and they don’t have time to follow proper deploying procedures, or when employees just disregard them. In the free text field we can add the isDirty flag and even list the count of pending changes and filenames, machinename used to compile, anything we come up with limited only by our imagination.

Even if the feature to add an IsDirty flag gets implemented, I would like to be able to extend it to list the dirty filenames/paths and the count of lines added/deleted, because in the past we even had to do reverse engineering over DLLs handed over by other dev teams that left the company, in order to know what was the version of the source code running in production and what parts were actually missing in git because someone deployed a dirty version and never pushed it to git! In that scenario the dirty filenames are a great help.

Also for CI/CD automation it would be very interesting to be able to add free text to assemblies that could be parsed by custom tools.

It is all about extensibility!

Speaking only as a user, but we wish to use AssemblyInformationVersionAttribute as a way of holding more detailed build information than can be obtained from the SemVer format. (For example, the date of the commit, name of build-machine/user, what the user ate for breakfast etc…) By all means, have a way of stuffing a SemVer-compatible string into this field but, please also allow for those of us who want to include arbitrary information. I’m aware we could create a custom attribute ourselves but since gitversion already does 95% of what we want in setting up the attributes, it seems a shame not to also use it for customised info.

The ‘flattening’ of characters into hyphens is particularly annoying when trying to treat the information field as structured data since dates and branch-names also regularly contain hyphens, a custom format such as assembly-informational-format: '{MajorMinorPatch} {CommitDate} {ShortSha} {BranchName} {env:USERNAME} {env:BREAKFAST}' can turn into

"1.7.6-2020-05-18-e1bbd7e-bug-fix-345-neilm-fried-eggs" which means extraction of fields is much more awkward.

Providing the warning at compile time is going to be difficult, but we could log a warning statement during execution.

I see the use-case of other languages for some sort of scheme for the GitVersion generated SemVer to adhere to their language/platform requirements.

However I feel that what we are trying to achieve with this bug/PR is something different. We just want to have a free text field to fill with whatever information (hence the informational name) using any character, so for this use-case, we are not trying to follow SemVer nor any scheme at all, and that should be a valid goal independently of the language or scheme used, as even the Python community might want to follow their schema but also have a free text template.

I feel that microsoft’s dotnet field AssemblyInformationalVersion was meant for this, just to give total free text, like a description, that’s why the field doesn’t even seem to have a maximum char limit.

Also the scheme feature mentioned in the Python bug, I feel it is far from being implemented because the problem of adding a “scheme” feature with different platform support requires deep knowledge of many other platforms and testing becomes harder. Even if it is a commodity for users, it also becomes a burden for this project that I think it would be better solved by using extension mechanism following the Open-Close principle, maybe python can have a library that wraps GitVersion and assigns the configuration that python expects, just like dotnet has the GitVersion.Task NuGet. It could be developed under the same GitTools group in GitHub, but it should not need changes in the main GitVersion project other than allowing proper extensibility if it is not already there. That way there would be no need for more configurations and the new parameter proposed in the PR would still make sense. I fear that the python/docker/PHP scheme issue would be blocking this PR unnecessarily for a long time, when this bug is in reality a simple one that could be solved today.

Maybe to accept this PR it would help to rename the new configuration parameter from: assembly-informational-is-semver: true to assembly-informational-allow-special-chars: false or assembly-informational-allow-any-character: false or assembly-informational-allow-free-text: false so it makes more sense in the case the scheme config gets added.

Would that help?

I created a pull request for this as I also need this feature: https://github.com/GitTools/GitVersion/pull/2341

Well, no, it’s the other way around. GitVersion generates a SemVer 2.0 compatible version number, then provides many different serializations and formats of this version numbers targeting different environments.

Since AssemblyInformationalVersionAttribute allows for a larger set of characters than SemVer 2.0, I think it’s natural to think that assembly-informational-format should only affect AssemblyInformationalVersionAttribute and thus allow characters not allowed in SemVer 2.0. I’m just not quite sure yet how to implement it.

The regex of characters allowed in a SemVer 2.0 compatible pre-release label is [0-9A-Za-z-]. So I suppose the question here is: Should we allow InformationalVersion to be incompatible with SemVer?

This change might have been introduced in #2014. Perhaps we need a more fine-grained replacement strategy here. 🤔