Skip to content

MajorMinorPatchTag - AssemblyVersion vs AssemblyFileVersion #544

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
veccie opened this issue Jul 28, 2015 · 9 comments
Closed

MajorMinorPatchTag - AssemblyVersion vs AssemblyFileVersion #544

veccie opened this issue Jul 28, 2015 · 9 comments

Comments

@veccie
Copy link

veccie commented Jul 28, 2015

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?

@JakeGinnivan
Copy link
Contributor

Is this in the Task or the exe?

@JakeGinnivan
Copy link
Contributor

@SimonCropp I think both should listen to the config?

@JakeGinnivan
Copy link
Contributor

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

@cjam
Copy link

cjam commented Sep 13, 2016

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.

@jensbrand
Copy link
Contributor

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

@asbjornu
Copy link
Member

I agree. Pull requests are welcome! 😄

@jensbrand
Copy link
Contributor

Ok, I will try to implement this.

@asbjornu
Copy link
Member

#1130 is merged, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants