True, that works for many files and I was going to suggest that originally.
However, I found that it doesn't seem to work when the results contain commas
as James' appears to have (since in his original email, he replaced commas with
periods). Here is what I found when I used the [Version] typecast with a comma
based result:
This will show us the results with commas:
PS C:\Users\aakash> (Get-Command 'C:\Program Files
(x86)\AutoIt3\AutoIt3.exe').FileVersionInfo.Productversion
3, 3, 8, 1
However, if we attempt to typecast this, it errors out:
PS C:\Users\aakash> [version](Get-Command 'C:\Program Files
(x86)\AutoIt3\AutoIt3.exe').FileVersionInfo.Productversion
Cannot convert value "3, 3, 8, 1" to type "System.Version". Error: "Version
string portion was too short or too long."
At line:1 char:1
+ [version](Get-Command 'C:\Program Files
(x86)\AutoIt3\AutoIt3.exe').FileVersionI ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvalidCastParseTargetInvocation
This is why I extracted the individual components and joined them.
So the more direct method that you mentioned does work if the version number
already contains periods, but does not appear to work when it contains commas.
However, if I missed something though, please let me know since it would be
nice if we can directly typecast the result of FileVersion.Productversion in
all cases.
Thanks,
-Aakash Shah
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael B. Smith
Sent: Thursday, April 3, 2014 3:14 PM
To: [email protected]
Subject: RE: [NTSysADM] PowerShell tidy-up
It's easier than that. :)
$FilePath = 'C:\Program Files\AppSense\Environment
Manager\Agent\EMCoreService.exe'
$ver = [Version]( get-command $FilePath ).FileVersionInfo.ProductVersion
If ($ver -lt [Version]'8.4.495.0')
{
#do something
}
But a great idea...
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Aakash Shah
Sent: Thursday, April 3, 2014 5:50 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] PowerShell tidy-up
Another option to help address the problem with 11.2 and 1.13 is to type cast
the version as a "[System.Version]" type. You can use this to get the version
number:
$FilePath = 'C:\Program Files\AppSense\Environment
Manager\Agent\EMCoreService.exe'
$File = Get-Command $FilePath
$FileVersionInfo = @(
$File.FileVersionInfo.FileMajorPart,
$File.FileVersionInfo.FileMinorPart,
$File.FileVersionInfo.FileBuildPart,
$File.FileVersionInfo.FilePrivatePart
)
$FileVersion = [Version]($FileVersionInfo -join '.')
Now to compare this against another file, you can use:
If ($FileVersion -lt [Version]'8.4.495.0') { #do something }
-Aakash Shah
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of James Rankin
Sent: Thursday, April 3, 2014 1:20 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [NTSysADM] PowerShell tidy-up
Very good point. Luckily what I am dealing with here should all start as 8.4
and have xxx.x as the last numbers, but I will pay a lot of attention to that
in future, cheers!
On 3 April 2014 21:16, Ben Scott
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Apr 3, 2014 at 2:59 PM, James Rankin
<[email protected]<mailto:[email protected]>> wrote:
> I did this quick bit of PS to check a file version number and then launch a
> patching process if it isn't at a certain level. It works OK but I am sure
> there is a much cleaner and more elegant way to do this. Any pointers?
More of an observation than a suggestion:
Testing version numbers is one of those things that you'd think
would be easy but ends up being ridiculously complicated. Removing
separators and just treating it as one big number seems like a good
idea unless you want to compare version 11.2 with version 1.13. Plus
some people throw in letters. Testing release dates might seem like a
good alternative, but if the publisher is maintaining multiple release
branches, patch release 1.1.42 might be released after major release
2.0.0. Blech.
If the possible version numbers are more controlled, your method is
usually fine.
-- Ben
--
James Rankin
---------------------
RCL - Senior Technical Consultant (ACA, CCA, MCTS) | The Virtualization
Practice Analyst - Desktop Virtualization
http://appsensebigot.blogspot.co.uk
