File Version and Product Version are identical?

Jan 16, 2012 at 2:26 AM

I configured my Version Seed file with the following values:

AssemblyVersionPattern: 1.0.1.0

AssemblyFileVersionPattern: 1.0.j.b

After the build, the resulting DLL has the following properties:

File Version: 1.0.12015.2

Product Version: 1.0.12015.2

I would have expected the Product Version to be 1.0.1.0 and the File Version to be 1.0.12015.2.  Is my expectation incorrect?

Jan 16, 2012 at 6:09 PM

Same problem here..

Coordinator
Jan 24, 2012 at 1:55 AM

I am guessing that you are right-clicking on the dll and looking at the properties in Windows Explorer.  Unfortunately, you're not going to see what you think you should be seeing.  It displays File Version is correctly - that is the AssemblyFileVersion.  Product version is a little different. It doesn't show you the AssemblyVersion.  I guess it might if the AssemblyFileVersion or AssemblyInformationalVersions don't exist in the actual assembly (although I haven't tried it).

If you have an AssemblyFileVersion and no AssemblyInformationalVersion, you will get the AssemblyFileVersion as the Product Version (that's what you are seeing)

If you have an AssemblyInformationalVersion then you will see that value in Product Version.  Try looking at the TfsBuild.Versioning.Activities.dll.  You will see a bunch of information that doesn't look much like a version number.  It has a time stamp of when it was built, a simple version number "1.5" and the ID of the person who requested the build (me).  All that stuff is the AssemblyInformationalVersion value.

It's all an issue around what they decided to display in Windows Explorer rather than what's really in the assembly.

I built a simple version "reporter" app that is on the site as a separate download.  If you use that app, it will show you the version values that you are looking for.

MarkNic

Feb 1, 2012 at 7:28 AM

I wanted also add such information to the AssemblyInformationVersion, but that is not accepted by the Code Analysis rules from Microsoft. It's intended use is a normal versionnumber (x.x.x.x).

Jaap

Sep 11, 2013 at 9:46 PM
Sorry for replying to an old-ish thread, but I have a need to update the AssemblyInformationalVersion

Long story short - client's IT group wants the "File Version" to not include additional build information but the Development group wants the additional build information stored somewhere. The compromise is to:
  • use AssemblyFileVersion for the IT group (this will show up as "File Version" as previously mentioned)
  • use AssemblyInformationalVersion for the Development group (this will show up as "Product Version" as previously mentioned)
I don't see any issues logged due to the fact that AssemblyInformationalVersion is not exposed and cannot be set to a value different than the AssemblyFileVersion. I might have the time later this week or next week to pull down the source code and see if I can figure out how to update the code to expose (and update) the AssemblyInformationalVersion. Before I do that, I wanted to verify that you will accept a patch request if there isn't an open issue logged (some groups / owners will not, so I try to remember to ask first).

Thanks,
Jim.
Coordinator
Sep 11, 2013 at 10:23 PM
Jim,

AssemblyInformationalVersion is exposed - so are all of the AssemblyInfo file key-value pairs. I use it all the time. While it may have been intended to be a number dot pattern like Assembly Version and Assembly File Version (#.#.#.#), AssemblyInformationalVersion can be a string with almost anything you want in it.

Regards,

Mark
Sep 11, 2013 at 11:29 PM
Mark,

Thanks for the speedy reply; I really appreciate it.

After getting your seeing the email notification of your message, I checked and I did find that AssemblyInformationalVersion is exposed; sorry for the "operator error" on my part.

However, now I have a different issue. Per the original message, what I want is
  • AssemblyFileVersion to use the pattern of "1.0.0.0" (which is the same number / pattern as AssemblyVersion). That is working just fine.
  • AssemblyInformationalVersion to have the "1.0.J.B" pattern that your documentation shows for AssemblyFileVersion. The expectation that I would be that the pattern would be set the same way as if I had used that pattern for the AssemblyFileVersion (e.g. for today I think that would be something like 1.0.13254.10). However, when I do this, I simply get the string "1.0.J.B" in the "Product Version".
Based on your reply where you say that "AssemblyInformationalVersion can be a string with almost anything you want in it", should I assume that this the value provided is being treated as a string literal without any pattern replacement? If that assumption is correct, is there any way (other than changing the code) to override that behavior? Or am I missing something obvious again? :-)

Thanks again,
Jim.
Oct 31, 2013 at 12:05 AM
I am experiencing the same situation as Jim and was hoping for confirmation.

Based on your reply where you say that "AssemblyInformationalVersion can be a string with almost anything you want in it", should I assume that this the value provided is being treated as a string literal without any pattern replacement? If that assumption is correct, is there any way (other than changing the code) to override that behavior? Or am I missing something obvious again? :-)
Coordinator
Oct 31, 2013 at 12:46 AM
David,

No, your assumption is wrong. The point of this add-on is to provide a pattern-based way to automatically add versioning information that would provide unique information on every build. If you look in the Version 2.0 Update Guide on page 7 you'll see a pattern that I've used many times:

Team Project: $TPROJ - Build Name: $BNAME - Requested by: $REQBY

That will give you project name, build name and who requested the build that is inserted into the AssemblyInformationalVersion. You can also put in date information if you like.

For me, AssemblyVersion is static. I set it during development and it is the version number that I am attempting to release: "2.5.0.0" for example. AssemblyFileVersion I add the ever increasing build number in the build or revision portion of the version number - every build will generate a uniquely versioned assembly. Finally, I create more human readable info in the AssemblyInformationalVersion that would allow me to look at the info and help me identify the actual source code that built the assemblies.

Mark