-
Notifications
You must be signed in to change notification settings - Fork 651
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
Comments
Is this in the Task or the exe? |
@SimonCropp I think both should listen to the config? |
@veccie feel free to submit a PR for this, I agree. We should respect that setting. |
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:
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. |
I totaly agree with cjam, this would be the best solution. |
I agree. Pull requests are welcome! 😄 |
Ok, I will try to implement this. |
#1130 is merged, so closing. |
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:
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?
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?
The text was updated successfully, but these errors were encountered: