Comments (9)
What is the
FileVersion
adding that informational version is missing?
I recall reading from somewhere in this repository, that the four-integer FileVersion is more reliably included in crash dumps than the more verbose version strings.
You could also make the about dialog display the generated ThisAssembly.GitCommitId
.
from nerdbank.gitversioning.
what is the difference between the file version and the informational version other than that the end of the file version has encoded commit id values and the informational version has the whole thing?
AssemblyFileVersion is also used as the PE header file version, so all tools recognize that version. It is limited to 4 integers.
AssemblyInformationalVersion is a .NET metadata unique thing that can only be observed with tools that know how to read managed assembly attributes. It allows free-form text so it's convenient to leverage that to display a longer commit hash as text.
What is the FileVersion adding that informational version is missing?
As I mentioned just above, FileVersion is the only one that is visible to every tool that can display a version for PE files.
should I take the nuget reference out of the version.json file then?
That's up to you. It seems like a waste though if you're not building packages.
I need them to be able to go to the about dialog and see which release version they have and tell me. It sounds like I can use the FileVersion for this and it will be plenty precise.
Yes, show the file version and/or the informational version. If you mean for them to report it back to you, the file version is the most succinct yet precise value you can show.
The other option I thought of is that for the about dialog I can use the FileVersion but construct a new version object and just manually set the last value to 0.
That's up to you. I haven't heard any customer complain about the 4th integer yet, FWIW.
And if you do construct your own Version object, don't include the 4th integer at all -- so that they only see 1.2.3
rather than 1.2.3.0
. The .0
at the end is misleadingly precise (and longer than necessary) when you force it to zero. Just omit it.
from nerdbank.gitversioning.
The behavior you see is the default behavior, and there are good reasons for it, but it can be overridden. Let's go over each one.
AssemblyFileVersion is not part of any binding contract. It isn't part of the assembly name. It tends to be 'very precise' as a result because it is the same version that is put into the PE header and what you see in File Properties for the version. Having the full precision volume here is useful because a.b.c versions are often ambiguous as far as which commit built them. But a.b.c.d versions where d includes 15 bits from the commit ID has never failed me at precisely identifying a commit. As a result, given a file version, you can always get back to the commit that produced it.
AssemblyVersion is part of the assembly name, and thus is part of the binding contract on .NET Framework (not so much for .NET 8). You don't want that to change with every commit typically, because that would mean folks who bind against you to either recompile against the newer library for every single commit, or the app that ships your library would have to update its binding redirects for every single commit.
If we take a page from semver, an update to the 3rd integer (c in a.b.c.d) is just a servicing update that should not change its API in any way. If we assume you're following that, the assembly version shouldn't change for just a servicing update, as servicing should just be a drop-in replacement rather than requiring binding redirect updates.
So given assembly version and assembly file version have different audiences and different ramifications for their values and changes to them, having the same value across both is not optimal for either value. This is why the default value is as it is.
from nerdbank.gitversioning.
That said, if you want the assembly version to be more precise, there is an assemblyVersion
property you can set in the version.json
file to make it more precise.
I'm not sure whether we have a provision to also make the assembly file version less precise, as no one has asked for that IIRC. But you could always do it yourself through manipulating the msbuild properties as documented in our doc/msbuild.md file.
from nerdbank.gitversioning.
You don't want that to change with every commit typically, because that would mean folks who bind against you to either recompile against the newer library for every single commit, or the app that ships your library would have to update its binding redirects for every single commit.
If the assembly does not have a strong name, then .NET Framework will happily bind to it even if the assembly version is higher than what was referenced. (Then you cannot install it in the Global Assembly Cache, though.)
from nerdbank.gitversioning.
Good point, @KalleOlaviNiemitalo. Also, if you don't strong name, other assemblies that are strong named can't reference yours (on .NET Framework). So IMO every library you mean to share should be strong named to maximize its reach.
from nerdbank.gitversioning.
Ok thank you for the detailed explanation. I think I'm tracking with the logic here, but just to explain further and make sure I have it correct...
So the idea is that AssemblyVersion
stays the same until I make some actual change that would break things. In that case I update the second value. This allows .NET loading to work without breaking in more situations. FileVersion
, however, is intended to identify the commit so the second 2 items are required for that. So I thought the informational version has the commit ID directly, so what is the difference between the file version and the informational version other than that the end of the file version has encoded commit id values and the informational version has the whole thing? What is the FileVersion
adding that informational version is missing?
So that does maybe highlight that my use case is a little different here. This is not a NuGet package that will be consumed publicly or by others (side note, should I take the nuget reference out of the version.json
file then?). This is an internal project for building commercial software and the different projects in the solution are only referenced internally. So I'm less concerned about consumers breaking (though I still try to update for breaking changes). I may, however, make changes that don't break any API but effect how end users use or see the software. In that case I need them to be able to go to the about dialog and see which release version they have and tell me. It sounds like I can use the FileVersion
for this and it will be plenty precise and maybe that's what I do. The only drawback is that the last number is longer for the user to report but that's certainly not a deal killer.
The other option I thought of is that for the about dialog I can use the FileVersion
but construct a new version object and just manually set the last value to 0. This would allow the user to see something like 11.0.2.0 which is really easy but then if for some reason I needed more precision I can ask them for file properties.
Thoughts?
from nerdbank.gitversioning.
@KalleOlaviNiemitalo ok that makes some sense. Not a big deal either way I'm just trying to understand fully to make the best decision on which way I go so appreciate you guys taking the time to respond. As far as the dialog, I would rather not show that long of a string so that users can quickly type out 'I have version 11.0.2.0' or whatever. I know they could take a screen shot of the id but no way they are going to type that out. I had actually missed the ThisAssembly
class though so thanks for pointing me to that, that's super handy...
from nerdbank.gitversioning.
Ok great, thank you so much for taking the time to educate me, I appreciate it!
from nerdbank.gitversioning.
Related Issues (20)
- Add current branch to ThisAssembly HOT 1
- WPF generates Assembly Version Info twice HOT 6
- [Question] How can I publish nightly version e.g. 4.8.0-nightly.{height}.{ciJobNumber}? HOT 2
- [Question] Using height only in branches that don't match publicReleaseRefSpec criteria HOT 1
- Simulate the future version HOT 3
- Consider inverting `Language` property special-casing HOT 2
- Compile errors in an F# project when setting NBGV_EmitThisAssemblyClass to false HOT 6
- Versioning flow HOT 7
- Is there a way to configure to not create AssemblyFileVersionAttribute HOT 4
- Error in ManagedGit when dealing with non-packed lightweight tags HOT 5
- PrivateP2PCaching.proj' could not be found HOT 4
- nbgv tool doesn't support Central Package Management HOT 6
- Warning about PrivateP2PCaching.proj HOT 5
- Support using tags as only source for version HOT 1
- Inherit with override for pathFilter HOT 2
- Version of a Project Reference defaults to 1.0.0.0 in deps.json file HOT 1
- [Feature request] Support partial / blobless clones HOT 1
- Support Calendar versioning HOT 10
- Get-commits errors out while get-version works HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nerdbank.gitversioning.