Understanding AssemblyFileVersion

A few days ago, I was messing around trying to update the information of a DLL that was built on a central TFS server.  I was using a custom activity to interpret AssemblyInfo.cs, and change certain values before the final DLL was generated.  I came across an interesting observation and would like to share these findings, and maybe shed some insights to people who encounter such a behaviour.

For my test, I set the AssemblyInfo.cs as follows, then proceeded to build that DLL:

  • AssemblyVersion =
  • AssemblyFileVersion = 1.0.<SourceControlNumber>.<Date:yyMMddHHmm>, which happen to be 1.0.427.1403112154

I then queried that DLL using 3 different methods

  • Using ls *.dll -r | % versioninfo
    • ProductVersion = 1.0.427.1403112154 (Qn: Where did Product Version come from?)
    • FileVersion = 1.0.427.1403112154
  • Using PS with .NET classes, I get (as expected)
    • FileVersion = 1.0.427.1403112154
    • AssemblyVersion =
  • Using the view file properties in windows explorer, I get
    • FileVersion = 1.0.427.51930 (Qn: Where did this value come from?)
    • Product Version = 1.0.427.1403112154 (Qn: Where did Product Version come from?)

The results of these queries are show below



Let’s tackle the Product Version question first.  MSDN says

ProductVersion first looks to see if the assembly containing the main executable has the AssemblyInformationalVersion attribute on it. If this attribute exists, it is used for bothProductVersion and CommonAppDataPath. If this attribute does not exist, both properties use the version of the executable file instead.

So, since we did not set a AssemblyInformationalVersion, the DLL defaults to use FileVersion instead.  From what we see, this seems like the observed behaviour.  However, when I subsequently tried injecting a AssemblyInformationalVersion, the DLL still continues to show the File Version.  This will need further research.  Please share if you know why this is happening.


Next,  the File Version value presented in the file properties window differs from the actual value retrieved via powershell/.NET.  This different may cause confusion to anyone looking at the FileVersion information.  I spent a fair bit of time trying out various permutation to try to understand the behaviour.  The breakthrough came when I set FileVersion = 1.0.427.2014, which gave me this:


In this scenario, both File Version report the same result.  Looking up MSDN yields the following:

A file version number is a 64-bit number that holds the version number for a file as follows:

Putting together a quick test app, we see that a ushort (unsigned short, 16 bit number) parse of the original 1403112154 yields 51930!


So it seems that although you can push values larger than 16bit into each subset of fileversion, file properties renders it as a 16 unsigned short.  Hence, if you need to use file properties to retrieve such information, keep each subset of version to be no larger than what ushort can hold.

Hopes this helps someone someday.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s