Reputation: 20050
I am trying to get the file version using C#:
string file = @"C:\somefile.dll";
Console.WriteLine(FileVersionInfo.GetVersionInfo(file).FileVersion);
For most files this is fine, however for some i receive results that are different than the ones presented in the Windows file explorer.
See the attached image: the file version presented in windows is "0.0.0.0", however the one i get using FileVersion property is "000.000.000.000".
I've tried using different versions of the .NET (2, 3.5, 4) which give the same results.
Anyone else experienced this issue?
Thanks Lior
Upvotes: 0
Views: 3821
Reputation: 2192
Two answers from 2011, each missing part of the picture.
Version information resources must contain version information in binary form and may also contain separate version information in string form.
The two are not constrained to match. Indeed, the string forms are not even constrained to be numeric, and can have all kinds of arbitrary text stuff in them.
In this case, what was compiled into the DLL file was this:
FileMajor
, FileMinor
, FileBuild
, and FilePrivate
thus end up as four integers with value zero.000.000.000.000
" and that's what FileVersion
comes out as.It's not showing the product version as the file version. It's showing the (free-format) file version string, not the (four 16-bit words) file version numbers.
The first added fun part is that the string form must match the current language and code page at runtime of the program reading the resource information out of the DLL. As you can see from the doco, the mechanism permits (potentially) each language+codepage to have its own, translated, variant of the file version string; and the APIs pull out the one that matches.
The second added fun part is that the properties dialogue in Windows Explorer will only show the binary form of the file version.
It just ignores the string form entirely.
(This is an undocumented Explorer quirk; that you will however find mentioned in several exasperated Stack Overflow comments over the past decade since this question was asked.)
But the version information as read out by Get-Item
in PowerShell or the System.Diagnostics.FileVersionInfo
class in .NET will yield both the string and binary forms that are compiled into the DLL as separate sets of information.
PowerShell presents this as a FileVersion
property that is a System.String
object constructed from the string form compiled into the DLL and a FileVersionRaw
property that is a System.Version
object constructed from the binary, four 16-bit words, form compiled into the DLL.
Upvotes: 0
Reputation: 81660
The reason is, in WIN32 API (and the file metadata), product versions are defined as string but file versions are defined as integer while in .NET, all of them are defined as integer.
If you use reflector and inspect FileVersionInfo
class, you can see that they are loaded differently:
this.productVersion = GetFileVersionString(memIntPtr, string.Format(CultureInfo.InvariantCulture, format, new object[] { codepage, "ProductVersion" }))
But:
this.fileMajor = HIWORD(fixedFileInfo.dwFileVersionMS);
this.fileMinor = LOWORD(fixedFileInfo.dwFileVersionMS);
this.fileBuild = HIWORD(fixedFileInfo.dwFileVersionLS);
this.filePrivate = LOWORD(fixedFileInfo.dwFileVersionLS);
Upvotes: 1
Reputation: 2682
It seems Windows Explorer are stripping leading 0s of the version parts.
Try creating an assembly with FileVersion 001.001.001.001, it will show as 1.1.1.1 in explorer. But your code would return the actual value (001.001.001.001).
EDIT:
Explorer will return 001.001.001.001 as ProductVersion, but only if AssemblyInformationalVersion isn't set, in which case it would return that as ProductVersion.
Upvotes: 1