The following should be simple questions, but I was recently surprised to learn otherwise:
· Did that patch really install?
· Are my servers using the same version of ReallyImportant.dll?
File properties in Explorer has been a reliable one-off method to read version numbers, but in today’s automation-heavy world it’s all about the PowerShell.
Unfortunately the default presentation of file version info in PowerShell is… sub-optimal.
What the what? This image shows that for the very same file PowerShell and file properties (Explorer) can report different version numbers. You can try this on various machines and OSes and get fun weird results. Eagle-eyed friends of mine found that on Windows Server 2008 R2 machines with SP1 + additional patches installed PowerShell will show pre-SP1 versions numbers on various DLLs. The example above is from Windows Server 2012 R2.
All FileInfos in my session now have FileVersionUpdated property. Due to default formatting our new property may not appear in some views. You can twiddle with the format descriptors or just use -Property on commands like Format-List as in the following example.
We can use our new property in scripts or commands to do things like compare versions between machines.
Geek mode: PowerShell type adaptation, SxS, and why this is happening
Executable files like EXEs & DLLs are described by several metadata fields including versions, dates, company, and so forth. Some of the fields are updated by patches and some are left alone. File properties (Explorer) and PowerShell were each showing a different subset of the available fields.