Update AssemblyInfo.cs option

[JakeGinnivan]

No description provided.

[robdmoore]

+1

[robdmoore]

Also, I'll probably trry using TeamCity's built-in option for this since the variables will be available from TC :)

[SimonCropp]

do u guys want me to send a PR with same approach used in GitFlowVersion?

[robdmoore]

I tried using TeamCity's built-in option last night - unfortunately it executes it before all build steps so the environment variables aren't set at that point. I ended up using MSBuild tasks.

How does GitFlowVersion do it @SimonCropp?

[SimonCropp]

injects a temp cs file (containing the attribute) into the build pipeline

https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersionTask/NugetAssets/GitFlowVersionTask.targets
https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersionTask/UpdateAssemblyInfo.cs

has the advantage of also working outside the build server

[robdmoore]

Wow that's really clever - nice one!

This is what I ended up doing with ChameleonForms:

1. https://github.com/MRCollective/ChameleonForms/blob/master/Build.proj
2. On CI server I execute it using MSBuild with the following parameters /p:Platform="Any CPU" /p:Version="%system.GitHubFlowVersion.AssemblySemVer%" /p:FileVersion="%system.GitHubFlowVersion.FourPartVersion%" /p:InformationalVersion="%system.GitHubFlowVersion.FullSemVer%"

[sgryphon]

I like how FourPartVersion is being used for the FileVersion (and FullSemVer for the InformationalVersion), but don't think that the AssemblyVersion should include the Patch number.

Under SemVer rules, changes in the Patch number can only be for backwards compatible bug fixes, which means that the assemblies must be version compatible, i.e. version 1.2.3.0 must be compatible with 1.2.4.0; in other words from the AssemblyVersion point of view both should be the same (i.e. both 1.2.0.0).

For example, you can see this in the .NET Framework assemblies (in the GAC), where the AssemblyVersion is always version 3.5.0.0 (or whatever the major/minor version is), whereas the file version is the full four part number (e.g. 3.5.30729.7903) and changes every hotfix / KB update.

Particularly with strong naming, it would be annoying to have to change (or use binding redirects) just for a patch update.

Even for minor updates it is debatable if the assembly version needs to be changed, as they should also always be backwards compatible. i.e. under SemVer rules version 1.5.0.0 must be usable by a client that is expecting 1.2.3.0 (although it may have new functionality).

If this is implemented, I suggest a choice of assembly version between major only or major + minor (but never including the patch number).

Of course, this can be created by using the correct variables, but I think GitHubFlowVersion_AssemblySemVer is currently a bit misleading as it includes the patch number.

[robdmoore]

I agree - that is a confusing name; especially given we are actually trying in some ways to be .NET agnostic.

The GitFlowVersion code that Simon included above does what you suggest with the assembly version, except it automatically detects if you are signing the assembly and makes the choice for you (include minor if not signing, don't otherwise). This seems to make sense.

Re: using the current assembly version for mine - yeah I was tossing up with using major.minor, but given this was a single variable rather than two I erred on the side of laziness. If we provide a built-in way of setting the assembly info then I agree with what you are suggesting / what GitFlowVersion does.

I'm sure jake will weigh in with his thoughts too (possibly after his crazy week at MVP Summit though :p

[SimonCropp]

@robdmoore so that was a yes to a PR ?

[robdmoore]

Yes from my point of view. Not sure about @JakeGinnivan :P

[JakeGinnivan]

I was planning to just look for all assemblyinfo.cs files in the repo and update (like teamcity). GithubFlowVersion works at repo level, not project level like GitFlowVersion

[JakeGinnivan]

Guys, could you take a look at #34, not sure the targets approach which @SimonCropp is using fits that well with the way GitHubFlowVersion works.

Also, does this project need a better name?

[SimonCropp]

@JakeGinnivan so what approach did u go with? is it documented somehwhere?

[JakeGinnivan]

@SimonCropp have updated readme with information about it. Check the FAQ section