use standard version for AssemblyInformationalVersion

[SimonCropp]

Currently the gitversiontask uses the AssemblyInformationalVersion attribute to stamp the assembly with some metadata

[AssemblyInformationalVersion("5.0.0-beta.1+32.Branch.release-5.0.0.Sha.4eaaa994842b7be39ae94d4515525acfddf982f1")]

However tools actually make the incorrect assumption that AssemblyInformationalVersion will actually be a valid version number. The most current one that has bitten me is ClickOnce. Since there is not way we can correct the assumptions of other shitty tools my plan is to inject a new custom attribute and put the valid version in AssemblyInformationalVersion.

Thoughts?

[gbiellem]

Until this is done we can't use do any syncomatic updates on the Platform Installer repo as it'll break the click once manifest

[distantcam]

Can we just nuke Clickonce from orbit instead? Please?!

What is considered valid? If we're just dumping major.minor.patch into AssemblyInformationalVersion then what's the point of populating it?

[johnsimons]

I think @danielmarbach also raised an issue about this.

[SimonCropp]

Can we just nuke Clickonce from orbit instead

@distantcam please raise that in the PI repo if u want to seriously discuss it

[SimonCropp]

@distantcam

What is considered valid? If we're just dumping major.minor.patch into AssemblyInformationalVersion then what's the point of populating it?

I dont know? perhaps there is no point?

[gep13]

Personally, I really like that this attribute is used to store the "full" version number. This provides easy traceability back to the source code, once an assembly has been deployed into the field. If you are going to change it to only allow a "valid" version number into the AssemblyInformationalVersion attribute, I would ask that this be done via a command line flag, so that we can still use it as is.

[andreasohlund]

+1 for a flag and make the simple version opt in

Sent from my iPhone

On 15 Jul 2014, at 08:28, Gary Ewan Park notifications@github.com wrote:

Personally, I really like that this attribute is used to store the "full" version number. This provides easy traceability back to the source code, once an assembly has been deployed into the field. If you are going to change it to only allow a "valid" version number into the AssemblyInformationalVersion attribute, I would ask that this be done via a command line flag, so that we can still use it as is.

—
Reply to this email directly or view it on GitHub.

[RemyDuijkeren]

I prefer to have the option to override the InformationalVersion in the GetVersionConfig.yaml and command-line, just like #315. I think this could solve this issue.

For NuGet the same problems exists. If $version$ is used in the .nuspec. then NuGet will use the AssemblyInformationalVersion as version when we pack. But by default GitVersion has a very long InformationalVersion, like 0.2.1-unstable.34+34.Branch.develop.Sha.e1107f4d977b3f0bd25f6a322834eccff0efbc1b, which is not allowed by NuGet (to long?). NuGet then switches to AssemblyVersion for the $version, which is not something you normally want.

If the AssemblyInformationalVersion would be 0.2.1-unstable34 then NuGet understands this and will even mark it as prerelease package. See also http://docs.nuget.org/docs/reference/versioning.

AssemblyInformationalVersion is the version you would normally use when talking to customers or for display on your website. See also http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin

[JakeGinnivan]

Maybe we could create a branch config option which is assembly-informational-version-format which you can go {majorMinorPatch}.branch.{branch} etc and we lookup variables to do the replace?

[SimonCropp]

@JakeGinnivan thinking that is the only option

[JakeGinnivan]

#368 tracks that issue