Nowadays you can get the FileVersionInfo from Get-Item or Get-ChildItem, but it will show the original FileVersion from the shipped product, and not the updated version. For instance:
(Get-Item C:WindowsSystem32Lsasrv.dll).VersionInfo.FileVersion
Interestingly, you can get the updated (patched) ProductVersion by using this:
(Get-Command C:WindowsSystem32Lsasrv.dll).Version
The distinction I'm making between "original" and "patched" is basically due to the way the FileVersion is calculated (see the docs here). Basically ever since Vista, the Windows API GetFileVersionInfo is querying part of the version information from the language neutral file (exe/dll) and the non-fixed part from a language-specific mui file (which isn't updated every time the files change).
So with a file like lsasrv (which got replaced due to security problems in SSL/TLS/RDS in November 2014) the versions reported by these two commands (at least for a while after that date) were different, and the second one is the more "correct" version.
However, although it's correct in LSASrv, it's possible for the ProductVersion and FileVersion to be different (it's common, in fact). So the only way to get the updated Fileversion straight from the assembly file is to build it up yourself from the parts, something like this:
Get-Item C:WindowsSystem32Lsasrv.dll | ft FileName, File*Part
Or by pulling the data from this:
[System.Diagnostics.FileVersionInfo]::GetVersionInfo($this.FullName)
You can easily add this to all FileInfo objects by updating the TypeData in PowerShell:
Update-TypeData -TypeName System.IO.FileInfo -MemberName FileVersion -MemberType ScriptProperty -Value {
[System.Diagnostics.FileVersionInfo]::GetVersionInfo($this.FullName) | % {
[Version](($_.FileMajorPart, $_.FileMinorPart, $_.FileBuildPart, $_.FilePrivatePart)-join".")
}
}
Now every time you do Get-ChildItem
or Get-Item
you'll have a FileVersion
property that shows the updated FileVersion ...
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…